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BUS AND RAIL FLEET SYSTEMS 
STRATEGIC PLAN 


;>| PURPOSE: This Bus and Rail Fleet System Strategic Plan provides the Los Angeles County 
Metropalian Tranportatien Authority (Metro) with a clear, actionable set of recommended projects 

to best support the needs of the agency’s fleet technology program, including the need to strengthen 

its customer-facing tools and information. Overall, the Strategic Plan represents a logical and phased 
blueprint for fleet and communications systems replacements to maintain them in a state of good repair 
and upgrades to significantly enhance functional and operational capabilities, while providing Metro with 
forward-looking technology solutions. Recommended projects have been mapped onto timelines with 
dependencies between projects identified along with overall Rough Order Magnitude (ROM) costs broken 
down by primary program areas. 


Metro SEPTEMBER 2016 E-1 


BUS & RAIL ITS STRATEGIC PLAN EXECUTIVE SUMMARY EXECUTIVE SUMMARY 


OVERVIEW & BACKGROUND 


The primary goals of the Strategic Plan focus on improving Metro’s operational efficiency and reliability along with 
customer satisfaction. These goals are supported by a series of fleet and communications systems upgrades and 
implementations recommended as part of the program projects and actions in the Plan. The recommended projects 
are focused on providing enhanced functionality, overcoming current system and communications constraints, 

and replacing key fleet systems nearing the end of their useful life. As an example, one of the many impetuses 

for the development of the Plan were the current issues with certain elements of the Advanced Transportation 
Management System (ATMS) that have become difficult to maintain, and replace as they are approaching the end 
of the product’s life. 


In order to define a set of achievable projects that support Metro’s overall bus and rail fleet systems program, 
this project began with a series of needs assessment workshops and interviews to identify current bus and rail 
needs, assess existing fleet and communications systems, and identify on-going and planned program systems 
development efforts. The findings were then summarized in an interactive workshop followed by the Technical 
Memorandum 1: Needs Assessment and Technical Memorandum 2: Communications Assessment. 


GOALS OF THE PROGRAM 


The primary goals of the Strategic Plan projects include the following: 


@ Provide reliable and robust voice and data communications for bus 
and rail. 


© Update/replacement of bus CAD system nearing end of life. 
@ Provide CAD tools for rail. 


@ Define modern, updated, and flexible architecture for on-board 
systems. 


Provide improved, robust, integrated traveler information systems. 
Support real-time access to onboard video 


Improve interfaces for SCADA systems 


Improve IT systems for bus and rail yards 
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Following completion of the needs assessment, an alternatives assessment was completed evaluating a series of fleet and 
communications alternatives identified to meet the broad range of ITS-related needs. Evaluation criteria were developed, 
which used a common approach and considered the technical ability of each alternative to meet identified needs, benefits, 
strengths, weaknesses, opportunities, threats, capital and O&M costs, implementation timelines, risks associated with each 
alternative, benchmarking of where each alternative may have been implemented by other transit agencies, and whether each 
alternative would require significant updating to work as technology advances (i.e., “future proofing”). The highest scoring 
alternatives were reviewed with key Metro stakeholders in an interactive workshop, followed by a technical memorandum, 
and then carried forward as the recommended projects for this Plan. The resulting program of projects outlined in this Plan 
represent the highest scoring and selected alternatives from the earlier analysis efforts. At each stage, a broad group of 
stakeholders from Metro departments including bus operations, rail operations, ITS, maintenance, communications, risk 
management, security, and others were involved in the evaluation and reporting of results. 


STRATEGIC PLAN RECOMMENDATIONS 


Several recommended technology solutions supporting improvements to Metro’s operating and business environments—and 
importantly, customer experience—have been identified over the course of this project. These solutions make up an overall 
technology program for Metro to implement over the next fifteen years in a coordinated and phased approach to replace and 
update aging ITS systems and improve customer-facing systems. The Strategic Plan also takes into consideration both current 
and planned Metro projects. 


The recommended projects presented in this Plan have been grouped into two main categories: foundational and 
supporting elements. Foundational projects improve the backbone of Metro’s fleet technology systems that will have the 
most significant impact on the improvement of operations, address the most needs, and have the greatest impact on other 
solutions. Supporting projects build upon these foundational elements to offer Metro and its customers a fully realized 
Strategic Plan. It is anticipated that timelines in the Strategic Plan may shift based on funding availability and changing 
priorities, but the relationships between the projects, the overall cost estimates, and the project scope elements will remain 
the same. 
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STRATEGIC PLAN RECOMMENDATIONS: 
FOUNDATIONAL ELEMENTS 


The following recommended projects are considered “foundational elements” for Metro to achieve the goals of the Strategic 
Plan and to meet the key needs identified. These foundational elements include: 


e Communications system improvements necessary to successfully implement several of the recommended 
projects and/or achieve the improvements envisioned 

e On-board architecture improvements necessary to best leverage the communications system and ATMS II 
improvements and position the agency to be prepared for implementation of emerging and future technologies 

e ATMS !! Bus and Rail implementation will serve as a backbone for all other bus and rail fleet systems, provide a 
reliable source of bus and rail fleet data, and improve operational efficiency through the use of new and improved 
tools that are currently available in the technology market. 


Communications Recommendations 


During the initial needs assessment phase, the existing conditions, technology trends, and telecommunications needs were 
documented as inputs to this Strategic Plan. While the recently upgraded voice radio system for rail was deemed sufficient, 
there are significant issues with the current capabilities of Metro’s mobile data communications for the bus fleet and the 
age of the radio equipment for the voice and data radio system. The needs assessment also identified a significant need for 
the establishment of data communications for the rail fleet to improve both operations and the accuracy of real-time rail 
predictions. The key communications recommendations are described in the table below. 


LTE 
COMMUNICATIONS RECOMMENDED PROJECTS wie 
C.2 Metro would deploy a single, flexible, high-bandwidth data solution for both bus and rail fleets. The data 
Bus Data - Establish cellular —_ solution would utilize a high-speed, broadband data communications system. A cellular data system 
service for Bus Fleet would offer better coverage and greater capacity than a traditional radio system and enable improved 
arrival predictions, video streaming, and real-time farebox communications. The cellular provider would 
maintain the network, reducing Metro’s ongoing O&M costs. In addition, the cellular data network could be 
implemented quickly. Drive tests should be conducted to determine which provider has the best coverage. 
C.5 LA-RICS LTE should also be considered as one of the options. By implementing a cellular data system, 
Rail Data — Establish cellular eto would avoid the high costs to repair a breakdown of the current aging ATMS data radio system and to 
service for Rail Fleet find spares. This solution is being widely deployed by transit agencies across the US. 
fa) Projects C.2 and C.5 must be largely complete before Metro can leverage the improved data 


communications platform in order to to provide the vehicle location reporting improvements under project 
A.5 necessary to support the recommended supporting systems projects. 


C.3 Metro would replace the entire current bus voice radio system with a new Voice-over-Internet Protocol 

Bus Voice — Establish VoIP for (VoIP) system. This system would most likely be replaced as part of a larger ATMS replacement effort, as 

Bus Fleet (with Radio Backup) the Computer Aided Dispatch vendor selected through an ATMS II procurement would need to provide 
the integration and management of the VoIP solution to be controlled by the Computer Aided Dispatch/ 

Automatic Vehicle Location (CAD/AVL) system. The VoIP solution would utilize a high-speed, broadband 
data communications system and would offer better coverage and greater capacity than a traditional radio 
system. The cellular provider would maintain the network, reducing Metro’s ongoing O&M costs. VoIP could 
also be implemented quickly. By implementing VoIP, Metro would avoid the high costs to repair a breakdown 
of the current aging ATMS voice radio system and to find spares. This technology is currently being 
deployed by a growing set of transit agencies worldwide and is available through a number of technology 
providers. The current Metro bus voice system could be modified and retained as a fallback option in the 


® event of emergencies. 
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A key recommended component of the onboard communication system is a Mobile Gateway Router (MGR), which is 

included as part of the recommended on-board architecture in this Plan. The MGR will enable the utilization of multiple 
communications paths, including cellular data (from multiple carriers), WiFi, LTE, LMR, and other networks to build 
redundancy into the implemented communication solution. Other communications related projects identified in the Strategic 
Plan include expansion of the Icom rail voice radio system to support future rail system expansions and modification of the 
radio system in the Red Line tunnels to include LA-RICS LMR channels when the LA County Sheriff migrates onto the LA-RICS 
LMR system. Finally, the communications plan should be revisited when the commercial cellular providers role out 5G service 
and again when they implement 6G service. 


ATMS II Bus and Rail Recommendations 


The Task 1 needs assessment identified significant needs related to ATMS, which is the CAD tool currently used by Metro to 
manage bus fleet operations. ATMS was implemented in 2004 and the on-board ATMS components and other subsystems 
are outdated, nearing end of life, and are in need of replacement/upgrade. In addition, significant needs were noted to 
enhance, update, supplement, and/or replace the dispatching and operations control functionality of ATMS. In some cases, 
this simply involved streamlined reporting and new methods of more rapidly and effectively getting information from ATMS 
to other systems. Needs were also identified for ATMS to better support multi-modal incidents (e.g. ability to coordinate bus 
bridges for rail operations). In short, enhancements are needed to get the right data to the right people at the right time. 


The Task 1 needs assessment also identified significant needs for CAD tools for rail fleet operations. Currently, rail controllers 
utilize the SCADA system to monitor train locations and utilize M3 to store incident information. Since there is no mobile 
data communication system, controllers can only communicate with operators via the voice radio system and rail vehicles 
do not report their vehicle location. Needs were identified for rail CAD tools to improve the method to log incidents, provide 

a message tool for communications between controllers and operators, implement data communications to and from the 

rail vehicles, improve the efficiency of data collection from the rail vehicles, and improve coordination of activities with bus 
operations. Including AVL capability with a CAD system for rail operations would help meet the need to improve the reporting 
of train location information and arrival predictions for customers. 


The recommended technology program for Metro presented in this Plan, therefore, includes a procurement of new CAD/ 

AVL system called ATMS II to replace ATMS. ATMS II would support both bus and rail operations and would improve the 
coordination between the bus and rail operations when there are situations that involve both operations such as bus bridges. 
Implementing a single CAD/AVL system for both bus and rail operations would be more cost effective than implementing 
separate CAD systems for each. For these reasons, a number of transit agencies have implemented or are implementing 
joint CAD/AVL systems for their bus and rail fleets. The following table provides an overview of the recommended sequenced 
ATMS replacement/upgrade projects for bus and rail. 
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ATMS II FOR BUS AND RAIL RECOMMENDED PROJECTS 


EXECUTIVE SUMMARY 


A1+A.2 The first step in the open procurement for the replacement of ATMS project will be internal Metro work to 
Prepare/Budget for ATMS obtain approval for the ATMS II project budget and to issue a request for proposals (RFP) for consultant 

ll for Bus and Rail with services for the requirements definition, design, development of a vendor RFP, and implementation support. 
Consultant Support and By engaging consultant support, Metro staff will be better able to remain focused on their primary objectives 


Procure Consultant Support of enhancing service delivery and improving customer experience. 


©@O 


A.3 + A.4 Utilizing the consultants engaged under A.2, Metro will develop a complete RFP package for an open 
Prepare for ATMS II procurement for the replacement of the ATMS system. It is anticipated this procurement will include the 
Procurement for Bus and Rail ATMS II central system, work stations, voice and data communications system replacements for bus and 
rail as described in the Communications Plan, and most, if not all, of the on-board architecture elements for 
fe) bus and rail described below. By packaging these elements together, Metro will benefit from cost savings 


when several projects in the Strategic Plan are implemented in conjunction as one project. Metro may also 


benefit from reduced O&M costs when several projects are implemented as one. 


A5 Metro implements the new ATMS II solution in two phases, starting with the bus fleet, then implementing 
ATMS II Implementation for ATMS II for the rail fleet during a second phase. ATMS II will replace the current ATMS system that is 
Bus and Rail nearing end of life. ATMS Il will utilize state-of-the-art technology to enable more efficient operations, 
improved voice and data communications, improved accuracy in vehicle location reporting and time of 
fe) arrival predictions, and improved CAD tools for Metro staff, which will allow them to more effectively 


manage incidents and to disseminate service changes and disruptions information to Metro’s ridership. 


Upgrade of the ATMS onboard components will enable Metro to migrate 
that will allow for flexibility in the communication systems used and flexi 
components. 


It is envisioned the ATMS II implementation will include the replacemen 
communication systems and the implementation of the rail data commu 


to a modern onboard architecture 
bility in the addition of new onboard 


of the ATMS bus voice and data 
nication system, along with the 


recommended emerging trends on-board architecture described in the 


ollowing section. 


Project A.5 is a foundational project and must be underway, along with substantial completion of projects 
C.2 and C.5, before most of the supporting systems projects can be successfully implemented. 
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On-board Architecture Recommendations 


The ATMS II implementation presents a unique opportunity for Metro to establish ITS on-board architectures for the bus 
and rail fleets that will enable the agency to more easily replace and upgrade onboard components by eliminating the use 
of proprietary hardware and reliance on a single equipment vendor. This is a trend that is taking place in other industries 
and is emerging in the transit industry. There is a strong potential for cost savings if the onboard components of the 
recommended onboard architecture are replaced and integrated in conjunction with the ATMS II implementation. 


The recommended bus and rail on-board architectures include common elements such as the mobile data terminal (MDT), 
mobile gateway router, GPS receiver, WiFi radio, automatic passenger counters, onboard video system, and onboard 
passenger information system that will result in cost savings due to economies of scale. It is recommended that the MDT 
for the bus, also be designed to serve as the control head for the farebox. The upgrade or replacement of other onboard rail 
components that interface to track wayside and rail control systems would not be a part of the ATMS project. Some of the 
recommended onboard components such as the MGR, APCs, and Wifi radio may be implemented by other Metro projects in 
advance of the ATMS II project 


To most effectively implement the emerging onboard architecture and realize the cost savings, a detailed definition of the 
on-board architecture should be included in the ATMS II requirements definition work and implemented as part of the ATMS II 
project. 


SUPPORTING SYSTEMS 


Supporting systems are those elements of the Strategic Plan that further support the improvement of operational efficiencies 
and overall cost reduction through the implementation of common platforms and single-sources of information along 

with improved ease of use for Metro staff interacting with the systems. Supporting systems have been grouped by major 
technology area and include: traveler information, SCADA, video, and yard management. Some of the recommended projects 
in these categories build upon the improvements achieved with the foundational elements, such as leveraging the improved 
data sources found in the ATMS II implementation for traveler information or the ability to support real-time on-board video 
streaming through the improved data throughput achieved in the data communications projects. 


Traveler Information 


The Task 1 Needs Assessment identified clear needs related to improved traveler information, including improving the 
quality of real-time location and prediction information for bus and rail, incorporating service adjustments/alerts into traveler 
information feeds, and consolidating the dissemination of traveler information on the electronic information signs and PA 
systems. 


The Strategic Plan recommends a set of projects categorized into the three overarching initiatives to help Metro meet these 
needs and greatly improve customer experience: 1) rail vehicle locations and arrival predictions, 2) multi-modal systems, 
including for service alerts, and 3) customer-facing systems. Improvements to vehicle locations and arrival predictions for the 
bus will be achieved through the implementation of the cellular data network and ATMS Il. 
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Rail Vehicle Locations and Arrival Predictions 


The need to improve rail vehicle location information and arrival predictions was identified as critical to improve both rail 
operations and the customer experience. These projects are necessary in order for Metro to operate a more robust multi- 
modal alerts system, expanding on the agency’s existing real-time passenger information platform to provide accurate and 
timely rail vehicle location data and arrival predictions. The following recommended, sequenced projects offer best practice 
solutions with a risk-averse approach to future proofing. 


RAIL VEHICLE LOCATION AND ARRIVAL PREDICTION 


RECOMMENDED PROJECTS 


T.4 This project deploys GPS receivers on rail vehicles, beacons at platforms/stations and along the track, as 
GPS + Track Wayside Circuits needed, to support improved rail vehicle location and arrival predictions. This approach minimizes cost by 
and Beacons for Rail Vehicle —_leveraging existing infrastructure and use of cost-effective hardware to fill gaps. While the current systems 


Locations largely meet operational needs, this additional level of granularity is necessary to provide more accurate 
and timely rail arrival predictions to customer information platforms. GPS data and beacons will augment 

fe) the track wayside circuit data to improve rail vehicle location reporting. While the costs of the GPS devices 
are part of project T.4, the cost for T.4 may ultimately be reduced if the GPS devices are installed on the 


rail vehicles as part of the ATMS II project (A.5). It is recommended that the T.4 project be in progress or 


completed when the T.5 project begins. 
T.5 This project develops a stand-alone arrival prediction engine for rail services to handle the specific rules 
Rail-specific Prediction and characteristics of rail vehicle travel and would improve Metro’s rail prediction capability beyond what is 
Engine currently available through NextBus. A rail-specific prediction engine would likely include factoring operating 
rules, such as maintaining a safe separation between trains; short-turns, diversions, bus bridges, and other 
real-time changes in service; and terminal operations in the prediction calculations. This project would 
fe) utilize the additional rail vehicle location data provided by Project T.4 to improve the accuracy of the real- 


time rail vehicle predictions. It is recommended that the projects T.5 and T.3 are in progress or completed 
when the T.6 project begins. 
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Multi-modal Systems and Service Alerts 


Metro stakeholders identified the need for a unified alerts system for bus and rail that more reliably shares system 
information to customers during service changes and disruptions, e.g. detours, bus bridges, etc. In addition, the transit 
information Metro provides to the public and other traveler information systems needs to be in standardized formats. While 
Metro provides schedule data through GTFS and arrival information through the NextBus API, a need was identified to provide 
data through the GTFS-realtime standard that leverages the existing GTFS schedule data by providing incremental updates 
where transit predictions are available. The consistency between the GTFS and GTFS-realtime datasets increases the utility 
and accuracy of websites and apps using this data, directly improving customer information. 


The following recommended, sequenced projects, build on work completed to improve rail vehicle location and arrival 
prediction, and directly address these needs and ultimately meet the core goal of providing better quality information to 
customers and thereby increasing their trust (and use) of Metro services. 


ALERT SYSTEM AND REAL-TIME INFORMATION AGGREGATION 


RECOMMENDED PROJECTS 


T.3 This project implements a new alert system to enter, manage, and disseminate alerts with a focus on 

Multi-modal Alert System streamlining the alert creation process and dissemination via multiple channels. This system will provide a 
platform through which alerts are entered into the real-time passenger information platform and should be 

fe) developed prior to the Enhanced Multi Modal Real-Time Aggregation System (1.6). 

T.6 This project builds upon the existing agency open data and API systems (i.e., developer.metro.net) to 


Enhanced Multi-modal Real- —_ aggregate information from ATMS II, SCADA, Multi-modal Alerts System, and, possibly, from bus predictions 
time Aggregation System + from NextBus to provide a single-source of traveler information including vehicle locations, arrival 
Single GTFS-realtime Feed predictions, and alerts. The project also includes the implementation of a new, single, GTFS-realtime feed 


a that will provide improved accuracy on customer-facing portals like the Metro website and mobile app. 
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Customer-facing Systems 


Metro stakeholders identified the need to improve the customer experience by making it easier for them to access traveler 
information. This will involve unifying the web pages available into an easier to navigate Metro traveler information website 
and mobile app. Web pages and apps that are able to leverage functionality from the customer’s smart phones and mobile 
devices, such as GPS locations, improve the customer experience. Metro stakeholders have also expressed a need to 
consolidate the systems used to provide information to bus and rail passengers at stations and stops. 


The following recommended projects also are envisioned to build upon the improvements of the other recommended Traveler 
Information projects. 


« 
CUSTOMER-FACING SYSTEMS RECOMMENDED PROJECTS ie 
TRAVELER 
INFO 
T.7 This project redesigns the Metro bus and rail arrivals web pages in order to provide real-time information 
Web pages with RTPI including schedule, real-time predictions, real-time vehicle locations, and service alert information. The 
redesigned pages will allow users to access real-time information for their specific route, direction, trip, 
fa) stop, or any combination thereof. These web pages could be integrated with either the NextBus API or the 
Bus and Rail Traveler Information System (TIS) API. 
T.8 This project replaces existing non-compliant signs with NTCIP-compliant signs at bus stops, rail stations, 
NTCIP-compliant Station and transit centers and implements a common sign control system. This project reduces the number of 
Signs with Common Sign systems required to maintain and operate, translating into direct operating cost reductions. The project 
Control also helps eliminate incorrect or inconsistent information being provided across the customer information 
fa platforms. The standardized signs should pull data from the Enhanced Aggregation System (T6). 
T.9 This project upgrades the public address (PA) systems to provide one consistent system across all rail 
Rail Public Address System Stations either through the implementation of new PA equipment or by upgrading existing PA systems at 
Upgrades rail stations to be compatible with the unified system. The unified system will increase the reliability of the 
PA system and remove the complexities of managing multiple systems. The increases in capital costs to 
fe) implement the new system would be offset by decreased operations and maintenance costs. A unified PA 
system will improve the transit experience of customers by providing a consistent experience across the 
system. Projects ATMS I! Rail implementation (A.5) and the Enhanced Aggregation System (T.6) should be 
underway first, as the PA system will pull data from both newly implemented systems. There may be some 


cost reductions if this project is rolled into the rail elements under A.5. 
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SCADA 


Metro stakeholders identified a significant need to make SCADA data available to other maintenance and security staff, in 
addition to the rail operations center (ROC) controllers. Although controllers at the ROC are primarily responsible for train 
movements, the nature of the current SCADA architecture also requires them to supervise and manage wayside systems and 
manage alarms, which are distractions from the higher priority of ensuring safe train movements. Maintenance staff, who are 
primarily responsible for the wayside systems, have limited direct access to SCADA information. 


The following recommended projects provide maintenance staff with different access to SCADA information and assist with 
the management of alarms. 


SCADA SYSTEM RECOMMENDED PROJECTS 


S.4 This project adds a SCADA interface for use by maintenance and security staff. The new SCADA interface 

SCADA HMI for Maintenance —_ would be constructed as an extension of the existing ARINC system with new workstations and new 
graphics that are optimized for maintenance functions but limit control capability to prevent accidental 

fe) interference with the ROC controllers. The new graphics would include alarms for maintenance and security 


staff. The primary benefit is freeing the ROC controller from being an information conduit for maintenance 
and security staff and improving the efficiency and effectiveness of ROC controllers who can focus on train 
movements. Maintenance staff will benefit with an interface that is designed to specifically meet their needs 
and thus improve their efficiency and effectiveness. Security CCTV staff will also benefit with improved 


alarm displays for security-related points in the SCADA system. 
$.5 This project implements a message gateway with an interface to SCADA to automatically send emails, 
SCADA Message Gateway texts, or phone messages as triggered by alarms or events in SCADA. Implementation of this gateway can 
be accomplished with off-the-shelf alarm notification products that can be integrated with the SCADA HMI 
fe) ARINC or utilize the ARINC SCADA platform to provide this functionality. The benefit of the message gateway 
is the reduction of the ROC controller workload. Controllers would still be able to maintain awareness of 


equipment readiness but would no longer need to contact maintenance responders. 
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Video 


Metro stakeholders, especially security and operations staff, have expressed a need for the ability to view video from vehicles 
in emergency and other situations. The need for real-time access to onboard video will provide improved security for 

Metro operators and enable staff to better assess the onboard situation. Also, the onboard video will help Metro controllers 
determine when there is a false alarm and avoid having to dispatch law enforcement personnel to the vehicle. 


VIDEO SYSTEM RECOMMENDED PROJECTS 


V.3 + V.4 This project implements the capability to stream onboard video from bus and rail vehicles to the BOC 
Video Streaming for Bus and = and ROC. It is recommended that the streaming only be done during emergency situations. This project 
Rail assumes each vehicle already has a cellular data connection as a result of the implementation of the Bus 


from where it is streamed to viewers during an incident. The key benefits of the streaming video are the 
improved security of the operator and passengers, and reduction of the need for the Sheriff's involvement 
when there is a false alarm. 


© Data (C.2) and Rail Data (C.5) projects. The video will be temporarily cached (but not stored) in the cloud, 


V5 ATMS II will include an interface to the onboard video system to enable video tagging during critical 
Video Tagging and Streaming __ situations and will include the capability to activate video streaming from the vehicles during these 


a situations. 


Yard Management 


Metro stakeholders have expressed key needs for an IT system to provide yard tracking and management functions for the 
bus and rail yards. The recommend project helps achieve the benefits from an IT system that will reduce the amount of 
manual labor currently performed by yard staff. 


YARD MANAGEMENT SYSTEM RECOMMENDED PROJECTS 


Y.4 + Y.5 This project implements an IT system to provide comprehensive yard management functionality for the 

Prepare for and Implement Metro bus and rail yards, and interfaces to other IT systems such as M3 via the TDB. The system uses 

Independent Bus + Rail devices such as RFIDs to accurately report the parking location of vehicles in spaces or tracks. Interfaces 

Yard Management System to M3 and HASTUS will support automated vehicle and operator assignments prior to and during the 

Integration with ATMS II operating day. Implementation of a Yard Management system that is independent of ATMS II will enable 
Metro to consider a broader range of custom options that are more commonly seen for intermodal 

fe) yard management. This solution will result in a reduction in the amount of manual labor performed by 
maintenance and operations staff and improve the efficiency of vehicle assignments and bus and rail roll 
outs. 
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STRATEGIC PLAN TIMELINE 


Timelines for the recommended foundational and supporting elements of the Strategic Plan projects are shown in the figure 


below. Projects relating to Autonomous Vehicles being planned by Metro will be important when the Strategic Plan is updated 
in five years and are shown in the timeline for reference. 
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PROGRAM COSTS OVERVIEW 


The following are rough order of magnitude (ROM) costs that have been developed for the recommended projects. Some of 
the cost estimates are based on costs provided by vendors and others are based on projected support required to procure, 
implement, and maintain the systems. 


PROJECT CAPITAL COSTS ($) 10 YEAR O&M ($) 
Bus Data, Cellular $2,516,000 $5,371,000 
Bus Voice, VoIP $5,072,000 $10,079,000 
Rail Data, Cellular $514,000 $1,212,000 
ATMS II Bus $68,267,000 $29,320,000 
On Board Architecture, Bus $2,436,000 $1,208,000 
ATMS II Rail $24,119,000 $14,800,000 
On Board Architecture, Rail $1,189,000 $874,000 
Rail GPS, Track Circuits, and Beacons for Rail Locations $2,772,000 $940,000 
Rail-specific Prediction Engine $562,000 $536,000 
Rail PA System Upgrade $1,985,000 $2,008,000 
Multi-modal Alert System $636,000 $1,027,000 
Enhanced Multi-modal Real-time Aggregation System + GTFS-realtime $1,871,000 $1,191,000 
Web-pages with Real-time Passenger Info $381,000 $433,000 
NTCIP-compliant Station Signs with Common Sign Control $6,815,000 $4,394,000 
SCADA HMI for Maintenance $683,000 $105,000 
SCADA Message Gateway $397,000 $12,000 
Video Streaming for Bus and Rail $6,120,000 $2,958,000 
Yard Management System $11,622,000 $5,699,000 


$137,957,000 $82,167,000 


There are some opportunities for cost reduction if certain projects are implemented concurrently due to a reduction in 
integration costs and duplicated hardware and project management costs. For example, if the implementation of data 
communications for bus and rail, VoIP, ATMS II Bus and Rail, and GPS tracking for Rail were implemented as a single project, 
the overall costs would be reduced by $8.1M. Other cost reductions can be realized if the software development costs for the 
Arrival Prediction, Improved Service Alerting, and Traveler Information Aggregation projects were implemented in conjunction 
with the ATMS II project. 


RECOMMENDATIONS SUMMARY 


In addition to the initiation of planning and securing the necessary approvals for the implementation of the Strategic Plan 
projects; the implementation of the Connected Fleet/Facilities project ensures the entire bus and rail fleets will be equipped 
with mobile gateway routers and have cellular data connectivity. Also, the new ESOC building should be considered as a site 
for the ATMS II central system for both bus and rail operations. 


This Strategic Plan should be a living document and updated periodically—every five years or when Metro priorities and 
funding changes and to reflect new technology trends. IT systems should be updated/upgraded every five years; and hosted 
and Software as a Service solutions should be considered at that time. 


Mi) Metro 


SEPTEMBER 2016 E-14 
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1 Overview 

The breadth and depth of bus and rail fleet systems 

currently utilized and planned for at Metro are extensive This section provides an overview of the Bus 
and represent unique challenges in terms of developing and Rail Fleet Systems Strategic Plan project 
a meaningful Strategic Plan that covers the knowledge by discussing project purpose, identified 
and issues required without becoming burdensome in its needs and subsequent alternatives analysis, 
use for longer-term planning purposes. The Strategic the existing Metro technology environment, 


and provides a high-level overview of Plan 


Plan presented here aims to outline a clear and 
recommendations. 


actionable set of projects that together provide Metro 
with a forward-looking transit technology program. The 
primary goals of the Plan, revisited and supported 
throughout, focus on improving Metro’s operational efficiency and reliability, as well as providing systems 
to improve the customer experience and satisfaction. 


lige: Purpose and Scope of the Strategic Plan and Concept of Operations 


This Bus and Rail Fleet System Strategic Plan (Plan) provides the Los Angeles County Metropolitan 
Transportation Authority (Metro) with a clear and actionable set of recommended projects to best 
support the needs of the agency’s fleet technology program, as well as strengthen its customer-facing 
tools and information. Overall, the Strategic Plan represents a logical and phased blueprint for fleet and 
communications systems replacements and upgrades to significantly enhance functional and operational 
capabilities while providing Metro with forward-looking technology solutions. The recommended projects 
have been mapped to timelines, with dependencies between projects identified along with overall Rough 
Order Magnitude (ROM) costs broken down by primary program areas. Concept of operation scenarios 
illustrate how the recommended projects will improve Metro’s fleet operations and improve the customer 
experience. 


1.2 How to Use This Document 


This document is intended for use by Metro department heads and lead staff as they work through 
internal budgeting efforts to enable them to better identify the best sequencing for and potential bundling 
of recommended projects. This also provides the supporting information necessary to justify the projects. 


The Plan has been organized into the following major sections: 


Executive Summary — The summary provides an executive-level overview of key Strategic Plan technology 
program goals, overall timeline for the various program elements, recommended projects, related project 
dependencies, and ROM costs. 


Section 1: Overview — This section provides an introduction to the Strategic Plan, describing the project 
background, Metro’s major needs, alternatives assessment methodology, and a high level description of 
the Strategic Plan recommendations. 


Section 2: Foundational Elements — This section describes the “foundational elements” for Metro to 
achieve its strategic goals and objectives and meet the needs identified. Foundational elements include 
communications system improvements, on-board architecture improvements, and the ATMS II for bus 
and rail implementation that will serve as a backbone for all other bus and rail fleet systems; providing a 
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reliable source for bus and rail fleet data, as well as improving operational efficiency through the use of 
new and improved tools available today. 


Section 3: Supporting Systems — This section describes supporting systems—elements of the Strategic Plan 
that further support improvement of operational efficiencies and overall cost reduction through the 
implementation of common platforms and single-sources of information along with improved ease of use 
for Metro staff interacting with the systems. Supporting systems have been grouped by major technology 
area and include traveler information, SCADA, video, and yard management. 


Section 4: Strategic Plan Timeline and Relationships between Fleet Systems — This section provides a 
timeline for the complete technology program described in this Strategic Plan. The timeline identifies key 
dependencies between current, planned, and recommended projects. This section also provides diagrams 
that identify new or updated system interfaces that will result from the implementation of the 
recommended projects. 


Section 5: Rough Order of Magnitude Program Costs — This section provides rough order of magnitude 
(ROM) costs with detailed costs for each recommended project, including ten years of operations and 
maintenance support. 


Section 6: Technology Trends and Impacts — This section provides a discussion of emerging and future 
trends and their impact on future projects. The technology trends will allow Metro to more easily and 
cost effectively implement future technologies. 


Appendix A: Concept of Operations Scenarios — This section provides scenarios that illustrate how the 
recommended systems will improve Metro’s operations and the customer’s travel experience. 


Appendix B: Technology Program Project Descriptions — This section provides descriptions for 
current/planned fleet system projects undertaken by LA Metro. 


Appendix C: Key Terms — This section provides a definition of key terms used throughout this document, 
including acronyms and other Strategic Plan-specific definitions. 


1.3 Background 


In order to define a set of achievable projects supporting Metro’s overall bus and rail fleet systems 
program, this project began with a series of needs assessment workshops and interviews to identify 
current bus and rail needs, assess existing fleet and communications systems, and identify on-going and 
planned program systems development efforts. The findings were then summarized in an interactive 
workshop followed by the Technical Memorandum 1: Needs Assessment and first iteration of Technical 
Memorandum 2: Initial Communications Assessment. Following completion of the needs assessment, an 
alternatives assessment was completed, evaluating a series of fleet and communications alternatives 
across the broad range of identified needs. Evaluation criteria used a common approach and considered 
the technical ability of each alternative to meet identified needs, benefits, strengths, weaknesses, 
opportunities, threats, capital and O&M costs, implementation timelines, associated risks, benchmarking 
by other transit agencies, and whether the alternative would require significant updating to work as 
technology advances (i.e., “future proofing”). The highest scoring alternatives were reviewed with Metro 
in an interactive workshop and then carried forward as the recommended projects for this Plan. 
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1.3.1 Major Needs Areas 


At each stage of the assessment and evaluation, the potential projects for Metro’s bus and rail fleet 
systems program were traced back to the critical needs identified during the initial workshops and refined 
throughout the project as new information came to light. These needs directly address improving 
operational efficiencies, customer experience, and safety and security and are detailed in the following 
major categories: 


e Better communication reliability and data throughput. This includes voice, data, and yard 
communications systems. While currently operating adequately, the existing bus voice radio 
system, including radio dispatch consoles, is aging with many components reaching the end 
of their useful life and needs to be replaced to ensure future reliability. There are also 
significant challenges with the current capacities, functionality, and coverage or lack thereof 
of Metro’s mobile data communications for both the bus and rail fleets. Data 
communication is the foundation of all modern fleet management systems and critical to 
providing more accurate and timely transit information to customers. As an exacerbating 
factor to the issues with mobile data communication, there are substantial constraints on 
the wireless data communications coverage and capacities in the bus and rail yards. Despite 
the relatively recent Aruba implementation for the bus yards, there are already capacity 
concerns that will only become more significant as data needs expand. Metro is undertaking 
some pilot efforts to test options for providing yard Wi-Fi coverage through unique 
partnerships, as well as testing new yard handheld tablet applications, and this Plan 
encourages further development along this path. 


° Enhanced and streamlined computer aided dispatching and incident management. While 
operating adequately in some respects, the current ATMS is an earlier generation CAD/AVL 
system that lacks state-of-the-art mapping, service adjustment/restoration functions, 
streamlined performance monitoring tools, and many other features that would improve 
operations and provide better information to customers. Metro bus controllers do an 
excellent job of using ATMS to capture incidents/events information, but do not have 
adequate tools to manage service impacts and interruptions. In short, ATMS is serving a 
valuable role to document what occurs on a daily basis, but it is lacking in tools to help 
proactively monitor and respond to operational issues. For rail controllers, SCADA solutions 
offer good train control and safety monitoring features. However, there is no support for 
text messaging between controllers and operations. This was viewed by ROC personnel as a 
major tool needed to provide timely and accurate information to rail operators for non- 
critical items. In addition, incident logging and reporting for rail controllers is currently done 
through M3, which has limited functionality and is not operationally integrated with SCADA. 


e Modern, updated, and flexible on-board architecture. While state-of-the-art at the time it 
was implemented, Metro’s current on-board systems architecture has become dated and 
consists of a wide range of devices, interfaces, and functionality. It is essential an updated 
on-board architecture be established for the bus and rail fleets that recognizes the unique 
elements of each and provides a more flexible foundation for future technology integration 
and improvements. 


° Robust, integrated traveler information systems. A core mission of any transit agency is 
providing transit customers with reliable and timely information on services and service 
interruptions. As mobile data and information technologies have evolved, the capabilities 
and expectations of transit customers have dramatically changed, and their demands for 
timely and accurate data have increased exponentially. While Metro does a good job of 
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capturing data for operations purposes, as well as providing improved information 
dissemination options, there are significant limitations of the current transit traveler 
information systems. 


e Real-time on-board video, video data storage, and distribution improvements. Video from a 
variety of fixed platforms/facilities, buses, and rail vehicles is a crucial security, safety, and 
risk management tool. It is also presents a primary challenge from a systems, 
communications, and operations process standpoint. While Metro is undertaking the digital 
incident management system (DIMS) project to better integrate and manage requests for 
video and its distribution, there are significant challenges in terms of the variety, age, and 
capabilities of the range of fixed and mobile video platforms. Rail and bus operations as well 
as security groups, have all requested the ability for live look-in for vehicles in emergency 
situations. Current security threats will continue to push for greater video capabilities and 
access. Bus controllers noted that a live look-in feature would allow for some much needed 
process changes in responding to false emergency alarms on buses, as a very high 
percentage of reported alarms end up being false and require a considerable amount of law 
enforcement resources to resolve them. 


Along with the above major needs areas, the following additional needs were identified and addressed in 
this Plan: 


e Improved SCADA Interfaces. Controllers at the ROC who use the SCADA HM are primarily 
responsible for train movements, but the nature of the SCADA architecture also requires 
them to supervise and manage wayside systems unrelated to train movements. The 
additional responsibility of the wayside systems is a distraction from the higher priority of 
ensuring safe train movements. SCADA provides monitoring, alarms, and control of 
equipment for the following systems: traction power, train control, electrical, mechanical, 
tunnel ventilation, communications systems, fire detection, security, and other 
miscellaneous systems. The alerts and information for rail operations and maintenance that 
SCADA generates are not easily accessed outside of the SCADA systems. Maintenance and 
security staff who are primarily responsible for the wayside systems have limited direct 
access to SCADA information 


e Improved Yard Management tools. Vehicle management, status tracking, and maintenance 
support functions performed by Metro staff at the maintenance facilities are currently done 
manually. Yard management tools could assist with tracking status of vehicles and vehicle 
maintenance/yard spotter functionality, while providing automatic integration of its data 
into M3. 


1.3.2 Alternatives Assessment Methodology and Outcomes 


The Alternatives Assessment Technical Memorandum was the third major element of the Metro Fleet and 
Communications Systems Strategic Plan, with the first two being the Needs Assessment and 
Communications Assessment. As part of technical efforts for this project, a series of fleet and 
communications systems alternatives were assessed across the broad range of Metro-defined areas of 
need. For organization purposes, the major sets of systems alternatives reviewed were again divided into 
the major needs areas, and each alternative was analyzed to assess the technical ability of the alternative 
to meet identified needs, benefits, strengths, weaknesses, opportunities, threats, capital and O&M costs, 
implementation timelines, risks of implementing the alternative, benchmarking where the alternative may 
have been implemented by other transit agencies, and whether the alternative will need significant 
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updating to work as technology advances. Each of the alternatives were scored and compared within the 
specific area being considered in order to provide inputs and suggested implementation paths for the final 
Fleet and Communications System Strategic Plan. The scoring and recommendations outlined in the 
alternatives assessment technical memorandum served as materials for discussion and review leading into 
the final stages of the project providing a short-hand for the completed technical analysis. Many of the 
alternatives overlapped or were interrelated. The alternatives assessment effort did not attempt to 
correlate all possible implementation paths; however, as feedback was received on the recommended 
alternatives, the implementation plan for interrelated alternatives has been addressed in the Strategic 
Plan itself. The recommended technology program described in this Strategic Plan was built based on the 
high-scoring alternatives from this phase of the project. 


1.4 Existing and Planned Systems 


Metro currently has several bus and rail fleet systems projects underway or planned that will impact the 
projects recommended in this Plan. In some cases, the current or planned projects are being leveraged for 
further technical advances, cost savings, condensed implementation timelines, or some combination of 
the three as described later in this memorandum. It is important for agencies to take this kind of 
programmatic view as it offers them the best options and opportunities to meet sometimes conflicting 
goals and objectives, such as whether the need for a reliable communications system supersedes the need 
to manage cost by implementing communications upgrades and replacements as part of the 
recommended ATMS II project. Further, any dependencies identified between planned and recommended 
projects have been included in this Strategic Plan as it will be critical for Metro to have a clear view of the 
assumptions upon which some recommendations were based on. 


15 Strategic Plan Recommendations 


Several recommended technology solutions supporting improvements to Metro’s operating and business 
environments and, more importantly, customer experience have been identified over the course of this 
project. These solutions make up an overall technology program Metro will be able to implement over the 
next several years in a coordinated, phased approach to replace and update aging ITS systems and 
improve customer-facing systems. The Strategic Plan also takes into consideration both current and 
planned Metro projects. 


The recommended projects presented in this Plan have been grouped into two main categories: 
foundational and supporting projects. Foundational projects improve the backbone of Metro’s fleet 
technology systems that will have the most significant impact on the improvement of operations, address 
the most needs, and have the greatest impact on other solutions. These include: 


° Communications system improvements necessary to successfully implement several 
of the recommended projects, achieve the improvements envisioned, and maintain 
the systems in a state of good repair. 


e ATMS II Bus and Rail implementation, which will serve as a backbone for all other bus 
and rail fleet systems, provide a reliable source of bus and rail fleet data, and 
improve operational efficiency through the use of new and improved tools that are 
currently available in the technology market. 


e On-board architecture improvements necessary to best leverage the communications 
system and ATMS || improvements and position the agency to be prepared for 
implementation of future, emerging technologies 
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Supporting projects build upon these foundational elements to offer the agency and its customers a fully 
realized Strategic Plan. It is anticipated that timelines in the Strategic Plan may shift based on funding 
availability and changing priorities, but the relationships between the projects, the overall cost estimates, 
and the project scope elements will remain essentially the same. Supporting systems have been grouped 
by major technology area and include: traveler information, SCADA, video, and yard management. Some 
of the recommended projects in these categories build upon the improvements achieved with the 
foundational elements, such as leveraging the improved data sources found in the ATMS I 
implementation for traveler information or the ability to support real-time on-board video streaming 
through the improved data throughput achieved in the data communications projects. 


In addition to the initiation of planning and securing the necessary approvals for the implementation of 
the Strategic Plan projects, implementation of the Connected Fleet Vehicles & Facilities project is 
important so the entire bus and rail fleets will be equipped with mobile gateway routers and have cellular 
data connectivity. Also, the new ESOC building should be considered as a site for the ATMS II central 
system for both bus and rail operations. 


This Strategic Plan should be a living document and updated periodically—every five years or when Metro 
priorities and funding changes or to reflect new technology trends. The update of this Strategic Plan 
should take into consideration other strategic plans developed by Metro and its regional partners. 
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Z Foundational Elements 

The following recommended projects are considered 

“foundational elements” for Metro to achieve its This section describes elements of the 
strategic goals and objectives and meet the needs Strategic Plan technology program that must 
identified. These foundational elements include be in place to not only support improved 


operations and customer experience today, 
but also to better prepare Metro for future 
technology solutions. 


communications system improvements, which are 
necessary to successfully implement several of the 
recommended projects and/or achieve the 
improvements envisioned; ATMS II for bus and rail that 
will serve as a backbone for all other bus and rail fleet 
systems providing a reliable source for bus and rail fleet data, as well as improving operational efficiency 
through the use of new and improved tools available in the market today; and on-board architecture 
improvements, which are necessary to best leverage the communications system and ATMS Il 
improvements and position the agency to be prepared for implementation of future, emerging 
technologies. 


Jad, Communications System Recommendations 


Metro operates a large and expanding bus and rail system for the County. The Strategic Plan includes 
strategies for how the communications systems need to support Metro’s IT systems that assist in the 
operation of the bus and rail fleets. During the initial needs assessment phase, the existing conditions, 
technology trends, and telecommunications needs were documented as inputs to the strategy. Some 
existing systems, such as the recently upgraded voice radio system for rail, were identified as being 
sufficient, while others were identified as requiring significant investment, such as the bus data 
communications system, due to insufficient capacity and age of the existing equipment. For systems that 
required significant upgrades or replacement, alternatives were identified and assessed utilizing the 
methodology described in Section 1.3.2. The highest rated alternatives are the recommended solutions 
discussed below in this document. Technical Memorandum 2: Communications Plan also provides more 
details regarding recommended implementation approaches. 


2.1.1 Bus Communications System Recommendations 


This section reviews the voice and data communications solutions recommended for Metro under the 
technology program described in this Strategic Plan. 


Voice Communications for Bus 


As discussed in the Needs Assessment phase (Task 2: Initial Communications Assessment), the bus voice 
radio system is nearing the end of its lifecycle and both on-board and central system equipment will need 
to be replaced within the near term of the Strategic Plan timeline. The following section discusses the 
recommended solution for voice communications for the bus fleet: a Voice over Internet Protocol (VoIP) 
voice communications system. Since VoIP is a relatively new technology compared to land mobile radio 
(LMR) systems, it is recommended Metro retain the current ATMS voice radio system as a fall-back voice 
communication option for a period of time to reduce risk. The voice radio system would be treated as a 
standalone solution and would only be utilized in cases where the VoIP system was not functional for 
some reason. The current ATMS voice radio is only recommended to be a temporary fall back solution 
until the agency is comfortable with the VoIP system, at which time the existing LMR system would be 
retired. 
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im Establish VoIP Communications for Bus Fleet 


Project: C.3 


For this project, Metro implements a new VoIP system. This system would be implemented as part of the 
larger ATMS replacement effort, as the Computer Aided Dispatch vendor selected through an ATMS II 
procurement would need to provide the integration and CAD control for the VoIP system. The VoIP system 
would utilize a high-speed, broadband data communications system. 


Benefits 

e A VoIP system will have better coverage and greater capacity than the ATMS voice radio 
system. 

e The cellular provider would maintain the network. 

e VoIP could be implemented quickly, much faster than the implementation of an LMR system 


and the capital costs would be significantly lower. 


e By implementing VoIP, Metro would avoid the high costs to repair breakdowns of the 
current aging system and to find spare equipment. 


Technical Analysis Summary 


VoIP solutions are a relatively recent option for the transit industry that have emerged in the last few 
years. However, as discussed in ATMS 2: Initial Communications Assessment, this is rapidly becoming the 
industry trend. This solution is based on the underlying assumption that a high speed, high bandwidth 
data network has been or will be implemented by Metro. This assumption is addressed in the subsequent 
section of this document on bus data communications. 


While the migration to VoIP is an emerging trend in transit for service mobile voice communications 
needs, it is not without risks. One of the significant benefits of having the voice network and the data 
communications network on two separate systems (as is the current architecture for bus 
communications) is the additional level of redundancy that comes with that. If there is a temporary 
network outage on the voice network for example, the data network may still be operating, allowing the 
continued tracking of vehicles and the ability to at least communicate with a bus via canned and text 
messages. If VoIP is implemented using the network used for data communications network, this 
redundancy would be lost. There are also concerns about network congestion affecting both data and 
voice communications, resulting in lost voice communications. This concern has been particularly 
identified with the use of cellular data networks. As well, because this trend is relatively new in the 
industry (the consultant team is only aware of four operational systems in the US), there is no guidance or 
recommendations on this technology from industry organizations such as the American Public Transit 
Association (APTA). However, it should be noted that VoIP is being used by various international transit 
agency fleets, including some European and Asian transit agencies which operate very large fleets that are 
similar to Metro in size. 


VoIP is a relatively recent technology that has matured from “emerging” into “mainstream” in the last few 
years. There are risks due to the lack of maturity of the technology and the lack of redundancy when both 
voice and data communications rely on a single network. There is additional risk that system availability 
may be limited during a catastrophe. These risks can be mitigated by implementing on-board routers that 
are capable of utilizing multiple communications paths, including cellular data (from multiple carriers), 


BUS AND RAIL FLEET SYSTEMS STRATEGIC PLAN 
Prepared for Los Angeles Metropolitan Transportation Authority by EIGER TechSystems 


September 2016 


radio system, Wi-Fi, and other networks. This would enable Metro to utilize the current ATMS voice radio 
system or other systems such as LA-RICS as a backup to VoIP. 


Benchmarking 


In the US, there are only four known VoIP implemented systems that have been in operation for some 
time. Many other agencies, including AC Transit and Foothill Transit are currently in the implementation 
phase of their VoIP systems. The four fully accepted US systems include: CENTRO in Syracuse, NY; SMART 
in Detroit, MI; NICE in Long Island, NY; WRTAin Worchester, MA. 


Some European and Asian examples of mature VoIP systems include: SMRT in Singapore, Ingolstadt GER, 
Luxembourg, Oldenburg GER, BKV Zrt, Budapest — Hungary, Mainzer Verkehrsgesellschaft mbH (MVG), 
Mainz — Germany, Kraftverkehr Wupper-Sieg AG (KWS), Leverkusen —Germany, Transportation Bureau of 
the City of Nagoya, Japan, and CTB/NWEB in Hong Kong. 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 
$5.1M $ 10.1M 


Additional cost break down information may be found in the ROM Section 5. 


Assumptions 


° Cellular data or another broadband data solution will be implemented in conjunction with 
or in advance of the implementation of the VoIP solution. 


Implementation Considerations 


This project assumes that a high-speed broadband data communications system (such as 4G LTE or LA- 
RICS LTE) will either be implemented in advance or in conjunction with the migration of bus 
communications to VoIP. Metro could continue to utilize the existing agency owned voice radio system as 
a back-up solution for as long as the equipment is operational or until Metro is completely comfortable 
with the stability and reliability of the VoIP solution. This work should be implemented as part of the ATMS 
replacement project, as the VoIP solution is largely a software based solution and one that will need to be 
heavily integrated with and controlled by ATMS Il. 


Implementation Schedule and Key Dependencies 


The timeline below illustrates the implementation of the VoIP solution for bus voice communications, its 
dependency on the cellular data network for bus communications project, and the recommended timing 
with the ATMS II project implementation. 


Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year & 
2017 2018 2019 2020 2021 2022 2023 
(C.2) 
(C.3) 
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Data Communications for Bus 


As discussed in the Needs Assessment phase (Task 2: Initial Communications Assessment), the bus data 
radio communications system is not meeting all of Metro’s operations requirements (such as vehicle 
location polling rates). The current system does not have adequate capacity to support future data needs 
and is nearing the end of its lifecycle. Both on-board and central system equipment will need to be 
replaced within the early phase of the Strategic Plan timeline. 


The alternatives assessment for bus data communications rated use of a commercial cellular data network 
highest with the LA-RICS network second. The cellular data option poses less risk to Metro, as the 
networks are already fully built out with full regional coverage and have the network capacity to support 
Metro operational needs. In addition, commercial cellular data plan costs have plummeted; competition 
keeps the cellular companies on a constant program of improving their network capacity and coverage; 
and 5G service is slated to be rolled out in 2020. However, the LA-RICS system offers much promise in 
terms of comparable data communications technology and may have similar coverage. The fact that the 
system will be owned, operated, and maintained by regional partner agencies may prove beneficial in 
terms of long-term costs and control of the network. Therefore, it is recommended that Metro consider 
proceeding with a more comprehensive analysis of both alternatives before making the significant 
investment in system replacement. 


Connected Vehicle: Establish (Commercial) Cellular Data Service 


for Bus Fleet 
Project: C.2 


Metro, following completion of a drive test to compare coverage from the cellular data providers, will 
migrate bus data communications to the commercial cellular data network with the best coverage and 
performance. Metro would purchase all new cell cards/radios and would subscribe to service on the cell 
network by paying monthly charge per card/radio on the network. Metro would no longer own or 
maintain site data radio equipment and maintenance of the on-board cards would become a shared 
responsibility between Metro and the cell provider. If the data network is implemented before the ATMS 
Il project, Metro would need to integrate the new cellular radio equipment with the current ATMS to 
maintain existing operational processes. 


Benefits 
e The cellular data network will have better coverage than a radio system. 
e The cellular data plan chosen will enable the vehicle location update rate to be lowered to 


30 seconds or less and would result in improved vehicle location reporting and improved 
accuracy of the passenger information systems. 
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The cellular data plan will include sufficient capacity for the buses to transmit additional 
vehicle health information and for buses in an alarm state to transmit real-time video clips 
to improve the security of the operator and passengers. 


Maintenance costs are lower than a Metro owned system because the system would be 
maintained by the cellular provider. 


The cellular data network could be implemented quickly with lower capital costs than a 
Metro owned system. 


By implementing a new data system, Metro would avoid the high costs to repair a 
breakdown of the current aging system and to find spares. 


Implementation of the cellular data network enables a VoIP solution to be possible for voice 
communications. 


Technical Analysis Summary 


Utilization of a cellular data network for bus fleet data communications best meets Metro’s data 
communication needs. The cellular data alternative scores well in virtually all of the evaluation categories 
including performance, and future proofing. The recent drops in cell data network pricing for transit 
agencies has made this data communication alternative attractive from not only a Capital but now an 
O&M standpoint. The fact that the networks are completely built out, means that the schedule for 
deployment is much shorter. Network capacity meets all of the agency needs and future upgrades lower 
agency risk. 


Benchmarking 


The majority of recent data communications systems have been implemented using commercial cellular 
data, including dozens of agencies across North America. Locally, Foothill Transit, Montebello Bus Lines, 
Culver CityBus, and Torrance Transit are employing a cellular data network for their SmartBus systems. 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 


$5.4M 


Additional cost break down information may be found in the ROM Section 5. 


Assumptions 


Metro continues to expand the pilot program to roll out on-board mobile gateway router 
technology for the full fleet and that this router would become the primary data 
communications manager for all functions including Wi-Fi, CAD/AVL, vehicle diagnostics, 
fare collection and video/security systems. The utilization of on-board routers, could be 
implemented as part of the project or in advance of it. While on-board routers are not 
mandatory to support the migration to cellular data, they are strongly recommended. 


All sites, network infrastructure and backhaul network(s) would be provided by the cellular 
data provider. 
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° Vendors provide a solution that is relatively easily integrated with either the existing ATMS 
or its replacement. 


° All mobile units will be replaced by cell data cards in mobile access routers. 


Implementation Considerations 


Determination of timing of a replacement of ATMS is critical, and if it is going to proceed in the near term, 
it is strongly recommended that the data communications system be replaced at the same time or be 
completed before the ATMS II implementation. This alternative could proceed very quickly since the 
commercial cellular networks already exist. 


Mobile Gateway Router (MGR) 


A robust MGR may already be installed on the buses as part of the Connected Fleet Vehicles & Facilities 
project before the cellular data network implementation begins. If the MGR has not yet been 
implemented fleet-wide, and if an MGR requirement is added to the bus data communications system 
project, an additional S5M in capital costs must be included. This recommendation was also included in 
the voice system replacement and should only be accounted once. 


The MGR is considered a critical component of the on-board system of the future for several reasons, and 
is addressed in much more detail in other sections of this Strategic Plan. Three of the key issues worth 
mentioning here relating to the MGR are as follows: 


1. The MGR will allow the vehicle to make use of the best available data network for each 
bus. This may include utilizing an agency (or partner) built Wi-Fi network in the bus yard 
or in other sections of the network, connected vehicle technology when available, and 
then transferring over to a cellular for wide-area network coverage; 


2. The MGR will support a more graceful transition to another wide area data solution in 
the future, without requiring significant impact on other systems. This “future proofing” 
of the data system, will allow Metro the flexibility to start with one data solution initially 
(e.g. commercial cellular in the near term), with the flexibility to switch to a different 
solution (e.g. LA-RICS or a subsequent migration into FirstNet), if their cost and 
performance become more preferable in the future; and 


3. The MGR supports the routing of particular network traffic in different levels of 
prioritization depending on conditions. For example, Metro may choose to enable full 
motion remote video viewing, but only when vehicles are in Wi-Fi or other high-speed 
networks. Specific traffic, such as fare collection or VoIP traffic, could always take higher 
priority over all other traffic. This type of functionality allows Metro to optimize and 
prioritize mobile data communications to best meet operational needs. 


Drive Testing of the Network 


Because of the investment associated with the bus data network replacement project and because of the 
importance of a high-quality mobile data network to support the voice system recommendation of VoIP, it 
is strongly recommended that Metro perform extensive due diligence on both the cell carriers’ networks 
and also on the LA-RICS LTE network. This testing can be carried out simultaneously for all networks with 
a coordinated drive testing effort, and data collection can be augmented and expanded, by equipping 
some operating vehicles with data collection equipment for a more extended drive test. 
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Drive testing should be performed by experienced wireless communications experts, and should collect 
data to test all networks for the following: 


e Coverage: categorized and mapped into different levels of received signal strength (RSS) 
throughout the service area; 


e =©Throughput: network bandwidth measured in Mbps at individual points in the network. It should 


be noted that throughput can vary drastically in different parts of the day due to network 
congestion. This should be factored into the test methodology. 


e Latency: speed (or delay) in which a signal is received from the time that it is sent; 
e Jitter: the variation in the latency over time. This is particularly important for supporting VoIP; 


e Packet loss: measured percentage of the failure of one or more data packets to reach their 
destination. Also important to support VoIP, as well as, other data applications. 


Figure 1 and Figure 2 show some real-world results of recent drive testing performed for another transit 
agency. This testing can help select between commercial cellular carriers or between commercial cellular 
carriers and LA-RICS to help determine if multiple carriers or multiple networks are required to meet 
Metro’s needs, and can help with the system design and its optimization in the future. 
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Figure 1: Example Throughput Probability Density Functions 
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Figure 2: Reported RSS for One Carrier 


Negotiate with both LA-RICS and Commercial Cell Carriers before Selection 


Cell carrier pricing is now available through the Western States Contracting Alliance (WSCA) pricing 
agreements for various data plans including pooled data plans, which can be very advantageous for transit 
agencies with wide variation between individual vehicle data needs. It is particularly worth noting, that the 
cell companies consider this kind of data communications to fall under the machine-to-machine (M2M) 
data category. M2M communications have an even lower cost than other voice or data plans. Because of 
the highly competitive mobile data communications arena, even the WSCA pricing can often be 
negotiated even lower, especially by agencies with large fleets and extended buying power. 


LA-RICS is currently not able to provide very detailed pricing information until an agency enters into a 
more formal stage of expressing interest. The true costs of “buying in” to the network along with more 
accurate monthly data plan pricing would be required to fully assess the capital and O&M costs of this 
alternative solution. Having the drive testing results along with more updated pricing from the commercial 
carriers would put Metro in a more advantageous position for these negotiations. 


Backup Systems 


If the drive tests show comparable coverage between the cell carrier’s networks and the LA-RICS network, 
and the costs are also comparable, Metro should consider utilizing LA-RICS as the primary data network 
for the bus fleet with a cell carrier’s data network as a backup. Since the cell data network would only be 
used as a backup, Metro could put the entire bus fleet in a low cost, low data usage pooled plan. 


If the drive tests show that the LA-RICS network shows good promise but needs further development to 
provide adequate coverage, Metro could still utilize LA-RICS as a the primary data network for the bus 
fleet and utilize the cell data network as a backup until the LA-RICS network is fully built out. 
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Migration to 5G 


As mentioned above, it is likely that the cell providers will be offering the opportunity to migrate to 5G 
within the next four to five years. 5G will bring significantly more bandwidth, but its pricing is uncertain. 
It is recommended that any cellular cards or chips that are procured be capable of supporting both 4G/ 
LTE and 5G. It is further recommended that Metro do specific negotiations around the 5G transition, to 
see if it is financially feasible at the time of procurement. 


Connected Vehicle Technology 


Metro is currently implementing a pilot test of Connected Vehicle technology on a couple of limited 
corridors with a grant proposal for the full Connected Fleet Vehicle & Facilities project. The data radios 
being deployed on this pilot are capable of transmitting in multiple bands, including Wi-Fi and Dedicated 
Short Range Communications (DSRC), which is a licensed spectrum dedicated only for transportation 
purposes. This ultra-high-speed and high bandwidth network may support Bus Signal Priority (BSP), transit 
safety applications still in development, and may support other agency data communications needs. While 
the Connected Vehicle technologies are very promising, they will not be fully deployed for a long period of 
time and are not, at this time, considered a wide area data communications alternative. 


Implementation Schedule and Key Dependencies 


The timeline below illustrates the implementation of the cellular data network for bus communications 
and how the timing of this project affects the implementation of the VoIP for bus voice communications 
solution and the ATMS II project. 


Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year & 


2016 2017 2018 2019 2020 2021 2022 2023 


(C.2) Connected Vehicle: Establish (Commercial) Cellular Data Service for Bus Fleet 
(C.3) Establish VoIP Communications for Bus Fleet 


(A.4) ATMS II Supplier Procurement for Bus & Rail 


2.1.2 Rail Communications System Recommendations 


The following section describes the communications system recommendations for rail. 


Voice Communications for Rail 


As discussed in the Needs Assessment phase (Task 2: Initial Communications Assessment), the rail voice 
radio system is a relatively recent implementation. If the new Icom voice radio system is adequately 
maintained, it should support Metro’s needs for the majority of the timeframe assessed in this Strategic 
Plan. Maintenance of the radio system includes ensuring there are no coverage gaps and there are 
sufficient licensed channels to support the voice traffic loads as Metro expands its rail service. While it is 
possible that Metro will need to begin an assessment of rail radio replacement options toward the end of 


September 2016 15 


BUS AND RAIL FLEET SYSTEMS STRATEGIC PLAN 
Prepared for Los Angeles Metropolitan Transportation Authority by EIGER TechSystems 


September 2016 


the Strategic Plan timeframe, there does not appear to be any compelling reason to consider migrating rail 
voice communications onto a single shared radio system with bus operations in the near future. 


Data Communications for Rail 


Metro stakeholders identified key needs for the establishment of a rail data communications system to 
enable data communications with operators and to wirelessly upload and download data to/from the rail 
vehicles. A data rail communication system will be necessary to support other projects in the Strategic 
Plan including ATMS II Rail and GPS tracking of the rail vehicles. 


As with the bus data communications recommendations, the alternatives assessment for rail data 
communications rated use of a commercial cellular data network highest with the LA-RICS network 
second. 


Connected Vehicle: Establish (Commercial) Cellular Data Service for 


Rail Fleet 
Project: C.5 


For this project, Metro implements a data communications system for rail in a similar manner as the 
implementation of the bus data communication system. 


Metro would purchase all new cell cards/radios that are rail certified and would subscribe to service on 
the cell network by paying a monthly charge per card/radio on the network. Metro would need to 
integrate the new cellular radio equipment with ATMS II. 


Benefits 

e Enables real-time data messaging to operators and other CAD functions 

e Enables real-time vehicle location updates, the update rate would be 30 seconds or less 
e Enables real-time transmittal of vehicle health information 

e Better coverage than a radio system. 

e Enables the streaming of real-time video from the vehicle 

e Maintenance costs are lower than a Metro owned system because the system would be 


maintained by either the cellular provider. 


e The cellular data network could be implemented quickly with lower capital costs than a 
Metro owned system. 


Technical Analysis Summary 


As with the analysis performed for bus data communications, utilization of a cellular data network for rail 
fleet data communications best meets Metro’s data communication needs. The cellular data alternative 
scored well in virtually all of the evaluation categories including performance and future proofing. The 
recent drops in cell data network pricing for transit agencies has made this data communication 
alternative attractive from not only a Capital but also an O&M standpoint. The fact that the networks are 
completely built out, means that the schedule for deployment is much shorter than for a radio system. 
The network capacity meets all of Metro’s needs and future upgrades lower Metro’s risk. 
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Benchmarking 


Santa Clara Valley Transit Authority (VTA), RTD and WMATA have implemented a cellular data solution for 
its rail operations. 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 
$ 514K $ 1.2M 


Additional cost break down information may be found in the ROM Section 5. 


Assumptions 


e Rail certified mobile units will need to be procured and installed. 


° Metro continues to expand the pilot program to roll out on-board mobile gateway router 
technology for the rail fleet and this router will become the primary data communications 
manager for all functions including Wi-Fi, CAD/AVL, vehicle diagnostics, and video/security 
systems. The utilization of on-board routers, could be implemented as part of the project or 
in advance of it. While on-board routers are not mandatory to support rail data 
communications, they are strongly recommended. 


° All sites, network infrastructure and backhaul network(s) will be provided by a cellular data 
provider. 
e Vendors can provide a solution that is relatively easily integrated with ATMS II. 


Implementation Considerations 


It is recommended that Metro continue to expand the pilot program to roll out on-board mobile gateway 
router technology for the rail fleet and that this router would become the primary data communications 
manager for all functions including passenger Wi-Fi, CAD/AVL, vehicle diagnostics, fare collection and 
video/security systems. 


Determination of timing of the ATMS II implementation is critical, and if it is going to proceed in the near 
term, it is strongly recommended that the data communications for the rail system be implemented at the 
same time or completed before the ATMS II implementation. This project can be completed very quickly 
since the commercial cellular networks already exist. 


The recommendations provided for the bus data communication system in Section 2.1.1 for a drive test, 
negotiations with both the cell providers and LA-RICS, backup systems, migration to 5G, and Connected 
Vehicle technology also apply to the rail data communication system project. 
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Implementation Schedule and Key Dependencies 


Drive testing (shown as C.1 below) should be completed prior to the implementation of any 
communications system project, including C.2 and C.5 that establish cellular service for the Bus and Rail 


fleets. 
Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year & 
2016 2017 2018 2019 2020 2021 2022 2023 


(C.1) Drive Test (cell + LA-RICS) 
(C.2) Connected Vehicle: Establish (Commercial) Cellular Data Service for Bus Fleet 


(C.5) Connected Vehicle: Establish (Commercial) Cellular Data Service for Rail Fleet 


The timeline below illustrates the implementation of the cellular data network for rail communications, 
and its linkage to the cellular data network communications for bus and the ATMS II project. 


Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 


2016 2017 2018 2029 2020 2021 2022 2023 


| a | 


(A.5i) ] 


(C.2) Connected Vehicle: Establish (Commercial) Cellular Data Service for Bus Fleet 
(C.5) Connected Vehicle: Establish (Commercial) Cellular Data Service for Rail Fleet 


(A.5i) ATMS II for Rail 


2.1.1 Additional Communications System Recommendations 


It is also recommended that Metro investigate LA-RICS’ plans for tunnel LTE services. The radio system in 
the tunnels of the rail system will need to be revised to provide coverage for the LA County Sheriff when 
the LA-RICS LMR system is completed and the LA County Sheriff migrates onto it. Metro should also 
investigate if LA-RICS has plans to extend its LTE service into the rail tunnels. If the LTE network is going to 
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be extended into the tunnels to meet Public Safety agencies’ communication needs, Metro might also be 
able to utilize this network for its data communications in the tunnels. 


2 ATMS II Bus and Rail 


The bus fleet currently utilizes ATMS to help manage its fleet operations. The Task 1 Needs Assessment 
identified significant needs to enhance, supplement, and/or replace the dispatching and operations 
control functionality of ATMS. In some cases, this simply involved streamlined reporting and new methods 
of more rapidly and effectively getting information from ATMS to related systems. In other cases, the 
needs were to support functions across modes (e.g. ability to coordinate bus bridges for rail operations). 
Task 1 identified the need to get the right data to the right people at the right time. In addition, the on- 
board ATMS subsystems and other subsystems are outdated, nearing end of life, and are in need of 
replacement/upgrade. An updated CAD system would include new tools to aid in service recovery. 
Including a new wireless data system with greater bandwidth than the current ATMS data system would 
help meet the need for more accurate vehicle location information and improved security if live video 
from a vehicle could be streamed on demand to the BOC. 


The rail fleet operations does not currently utilize a CAD system. Rail controllers utilize the SCADA system 
to monitor train locations and store incident information in M3. There is no data communication system 
so controllers can only communicate with operators via a voice radio system. The Task 1 Needs 
Assessment identified needs for CAD tools for rail operations to improve logging incident information, 
provide data communications and a messaging system, improve the consistency and accuracy of 
information, and improve coordination of activities with bus operations for bus bridges. Including AVL 
capability with a CAD system would help meet the need to improve the reporting of train location 
information. Including a wireless data connection to the vehicles with an on-board CAD system would help 
meet the need to automate collection of vehicle data and save the time and costs of collecting the data 
manually, to provide enhanced easy to understand customer information on board the vehicles, and to 
provide improved security if live video from a vehicle could be streamed on demand to the ROC. 


For the Task 3 alternatives analysis, Task 4 SWOT analysis, and Task 5 Cost Benefit Analysis, it was 
assumed that all of the CAD alternatives considered for bus operations would in general provide the 
features desired by Metro and would meet the needs identified in the needs assessment. The 
differentiators between the alternatives primarily were the costs, future proofing, and which alternative 
would best meet Metro’s needs. For the CAD alternatives for rail operations, it was assumed that the first 
three alternatives would in general provide the features desired by Metro and would meet the needs 
identified in the needs assessment. The fourth alternative was scored lower in performance, risk, meeting 
agency needs, and future proofing because ARINC, the SCADA vendor for Metro, does not currently offer 
all of the CAD tools and features desired by Metro, while the CAD products offered by other vendors do. 


The highest rated alternative from the assessment of CAD for bus operations and for rail operations was 
the same: procure and implement a new CAD system that supports both bus and rail operations. A single 
CAD/AVL system best meets LA Metro’s needs--providing efficient and effective CAD tools for both bus 
and rail fleet operations and improved coordination between the bus and rail operations when there are 
situations such as bus bridges. Implementation of a single CAD/AVL system for both bus and rail 
operations is also more cost effective than implementing separate CAD systems for each. A number of 
transit agencies have implemented or are implementing joint CAD/AVL systems for their bus and rail 
fleets. 
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This project will begin with the development of a high level design and technical requirements for ATMS II 
Bus and Rail by a consultant. ATMS II would be procured using an open procurement. The ATMS II project 
should include implementation of the emerging onboard architecture that is recommended in Section 2.3. 


The following paragraphs provide details of the recommended ATMS II Bus and Rail project. 


a= ATMS II Bus and Rail 


* “\ @Projects: A.1, A.2,A.3,A.4,&A.5+A.5i 


This project involves an open procurement for a replacement of the ATMS CAD/AVL system for the bus 
fleet operations and to extend the new CAD/AVL system to support rail fleet operations. The new state-of- 
the-art CAD/AVL system would include new CAD workstations for the bus operations center (BOC), rail 
operations center (ROC), and Bus and Rail Divisions; servers; CAD software; and new on-board hardware 
for the buses, rail vehicles, and supervisor vehicles. The onboard hardware for the buses and rail vehicles 
include MDT, WLAN radio, GPS receiver and other AVL hardware, on-board processor, router; cellular 
modem; APCs; internal LCD signs for infotainment; interface to the farebox, headsigns, public address (PA) 
system, on-board video system, and on-board vehicle health monitoring systems; and county-wide signal 
priority capability. The vehicles for road supervisors and field supervisors will include a GPS receiver and 
other AVL hardware, cellular modem, and a removable laptop or tablet. 


Some of the features of ATMS II include: interface to a cellular data network for VoIP communications and 
data communications with the fleet vehicles, vehicle location and schedule adherence tracking and 
reporting, vehicle location map displays and vehicle status displays, incident and event logging, automated 
onboard stop announcements and other passenger information, automatic passenger counting, silent 
alarm with covert microphone monitoring and streaming video, interface to the farebox for a single point 
logon and location tagging of fare transactions, automated display of route and destination information on 
headsigns, transit signal priority that conforms to the Countywide Signal Priority architecture, database to 
TDB interface, and robust report generator. 


Benefits 


e ATMS II with state-of-the-art CAD features would result in improved effectiveness of the 
controllers in managing bus operations and rail operations and resolving incidents. ATMS || 
will provide improved CAD tools for bus operations and a completely new set of CAD tools 
for rail operations. ATMS II will include tools that provide more accurate vehicle location and 
vehicle data such as passenger counts, vehicle health data, and onboard video during 
emergencies. ATMS II will provide improved map displays that will also provide traffic 
information, satellite and street level images. Other tools include more user friendly detour 
creation, increased electronic storage for previously created detour routes, forms and 
manuals, improved playback, spell check, bus bridge tool, arrival predictions, improved 
transfer protection between buses and bus and rail, and Al type recommendations for 
courses of action. 


e For rail operations, ATMS II will provide a new messaging capability between controllers and 
operators that will reduce the amount of voice calls on the ICOM voice radio system. 


e ATMS II’s CAD tools will provide greater efficiency in logging incident information by BOC, 
ROC, Division, and supervisor personnel. ATMS will include state of the art report generation 
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tools that will enable faster generation of fleet management reports and dashboard style 
reports for Division staff and supervisors. 


e The ATMS II on-board system will result in improved effectiveness of the operators in 
communications with controllers, and logging data. The MDT will provide operators with a 
color touchscreen terminal with improved ability to view messages, log pre-trip information, 
view route information, and send canned messages. 


e The ATMS II onboard router will enable the vehicles to have flexible communication paths. In 
case the cellular data network is unavailable, the router will switch bus voice 
communications from VoIP to the ATMS voice radio system. The router will enable data 
communications to switch to Wi-Fi when the vehicle is within range of a suitable WLAN 


network. 
e State-of-the-art APCs will replace aging APCs and improve passenger count accuracy. 
e ATMS Il onboard LCD monitors will provide content rich passenger information including a 


list of the upcoming stops, general service announcements, and real-time alert information 
sent by the controllers. The PA system will provide similar audio information. 


° The ATMS || onboard on-board system will enable vehicle health and other vehicle 
information to be automatically retrieved wirelessly. 


° ATMS II will have new or improved interfaces to other IT systems such as M3, SCADA, 
HASTUS, and traveler information systems that would eliminate manual entry of data into 
the other IT systems. 


e The ATMS II hardware will be more reliable and will replace aging ATMS hardware that is 
becoming increasingly difficult and costly to maintain. 


Technical Analysis Summary 


ATMS II will replace the current ATMS CAD/AVL system that is nearing end of life. ATMS II will utilize state- 
of-the-art technology to enable more efficient operations, improved voice and data communications, 
improved accuracy in vehicle location reporting and time of arrival predictions, and improved CAD tools 
for Metro staff to manage incidents and to disseminate service changes and disruptions information to 
Metro’s ridership. Upgrade of the ATMS onboard components will enable Metro to migrate to a modern 
onboard architecture that will allow for flexibility in the communication systems used and flexibility in the 
addition of new onboard components. 


CAD operations will be more efficient because the controller will have more accurate and timely vehicle 
location information. Currently, bus locations are only updated every three minutes. The update rate will 
be reduced to 30 seconds or less when a cellular data network for the bus fleet is implemented in 
conjunction with ATMS Il. Rail locations will also be updated every 30 seconds or less. ATMS II will provide 
map displays showing vehicle locations on street maps that will provide more detailed information than 
what is currently provided to the bus and rail controllers. The map displays will also provide vehicle status 
information, traffic conditions, and satellite images as shown in the examples below. 
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CleverCAD Map MDT 
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Example of Map Display Showing the Nearest Supervisor Vehicle to a Selected Bus 
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Example Map Display Showing the Display of Traffic Information 


ATMS II will provide tools to aid controllers in managing incidents by automatically routing notifications to 


maintenance, alert systems, security and social media. Some CAD vendors offer decision making support 
features and alert notification features when there is a need for service adjustments. ATMS II will include 
interactive service adjustments tools and a user friendly tool for detour generation. 
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Example of a Modern CAD User Interface for Ad hoc Creation of Detours 


Detour generation will be one of the tools provided by ATMS II to manage bus bridge incidents. Since both 
rail and bus operations will be using ATMS II, bus and rail vehicle locations will be provided to both 
operations as well as a connection protection tool. 


Example of a Modern CAD User Interface for Bus Bridges 
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ATMS II will include a logging tool to create electronic records of incidents that can be stored ina 
database. The data will be available for the generation of fleet management reports and dashboard 
summaries. 
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Example of a Business Intelligence Reporting Tool Interface 


ATMS II will monitor the status of onboard equipment and provide real-time equipment alerts as well as 
data that can be used to schedule preventive maintenance. 
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Example of a System Dashboard for Vehicle Health Monitoring 


The ATMS II onboard equipment will consist of an onboard processor, color touchscreen MDT, automatic 
passenger counters, automatic voice annunciation and passenger infotainment LCD monitors, GPS 
receiver and other AVL hardware, mobile gateway router, WLAN radio, interfaces to the onboard video 
security system, headsigns and other onboard vehicle systems. On the buses, the ATMS I! MDT will also 
provide a user interface for the farebox and the router will be configured to provide data communications 
for the farebox/TAP system. The onboard processor will calculate the vehicle’s location and determine the 
vehicle’s schedule and route adherence. The processor will also provide onboard TSP functionality that 
sends signal priority requests to signal controllers that conforms to the LA Countywide Signal Priority 
architecture. 


The MDT will display schedule adherence information, text messages from controllers, and can show turn- 
by-turn directions for detours and bus bridges. The MDT will enable operators to log onto ATMS Il and the 
farebox, send canned messages to controllers, record pre-trip information, and initiate public service 
announcements on the PA system and the onboard monitors. 
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Example of a Modern MDT Display. 
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Example of an MDT Display with Turn-By-Turn Navigation 
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Example of an MDT Display with Arrival Information 


The recommended on-board architecture for the bus and rail fleets is discussed in greater detail in Section 
2:3: 


Benchmarking 


A number of agencies have implemented or are planning to implement CAD/AVL systems that support 
both their bus and rail fleet operations including the SFMTA (San Francisco, CA), CapMetro (Austin, TX), 
VTA (San Jose, CA), SORTA (Cincinnati, OH), TriMet (Portland, OR), and SunTran (Tucson, AZ). 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 

Bus: $68.3M $29.3M 

Rail: $24.1M $14.8M 
Additional cost break down information may be found in the ROM Section 5. 
Assumptions 


e ATMS II will be implemented in conjunction with the implementation of a cellular 
data network for data communications and VoIP for voice communications. 


° Costs are based on ROMs received from CAD/AVL vendors. 
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° Capital costs include contractor project management costs for meetings, design 
reviews, training, acceptance tests, pre-acceptance system support, and 
performance bond; BOC, ROC, Division, and onboard vehicle hardware and software; 
manuals, design documents, and drawings. 


e ATMS II planning, design, and implementation costs assume adoption of the 
Emerging Trends on-board systems architecture. Overall, adoption of this 
architecture should save future operations and system lifecycle costs by reducing 
equipment replacement and integration costs for new elements and functions. 


e O&M costs include contractor provided hardware and software warranty support for 
10 years. 


Implementation Considerations 


Some elements of ATMS II may be implemented in advance of the ATMS || backend. The timing of these 
early implementations would be based on ongoing projects and Metro needs. Implementation of the 
onboard router will most likely occur as part of the Connected Fleet Vehicles & Facilities project. The 
Connected Fleet Vehicles & Facilities project is a foundational element of adopting the recommended 
Emerging Trends on-board architecture. Implementation of other onboard components such as new APCs 
may occur in advance of the ATMS || implementation due to the age of the existing hardware. Some of the 
older onboard video systems may need to be upgraded to enable real-time video streaming as part of the 
ATMS Il implementation. The ATMS Il implementation may need to be delayed if it is determined that the 
ATMS II backend will be installed in the ESOC building. The recommended Emerging Trends on-board 
systems architecture should be recognized early in ATMS II planning and procurement, and be maintained 
over time as part of the larger Fleet and Communications Systems configuration management efforts. 
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Year 1 


2016 


Implementation Schedule and Key Dependencies 


Year 2 


2017 


Year 3 Year 4 Year 5 Year 6 Year 7 


2018 2019 2020 2021 2022 


(A.1, A.2, A.3, A.4, + A.5) 


Year & 


2023 


(0.4) Requirements for New/Transitional Onboard Architecture 0.7) Fleetwide MGR (and cellular data) for Rail Vehicles 


(0.5) Fleetwide MGR (and cellular data) for Bus 


A.X) ATMS II efforts:: 


(A.1) Planning and Approvals: 10/2016 To 3/2017 


0.8) Emerging Bus + Rail Architecture Implementation 


A.4) ATMS Il Procurement: 7/2018 To 3/2019 


(A.2) Procurement of Project Support: 4/2017 To 12/2017 A.5) ATMS Il Implementation — Bus: 4/2019 To 8/2023 


(A.3) Preparation for Procurement: 1/2018 To 6/2018 A.5i) ATMS II Implementation — Rail: 4/2020 to 8/2023 
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Relationship to On-board Architecture Recommendations 


As part of the ATMS II project efforts for bus and rail, it is recommended that a new on-board architecture 
be adopted to support: less dependency on a single vendor, improved on-board communications options, 


improv 


ed compatibility between certain bus and rail technologies, on-board Ethernet/IP network 


connectivity, and improved project lifecycle for equipment/components and lower integration costs over 
time. Implementing and sustaining this new on-board architecture will take some addition effort during 


ATMS | 


| planning, procurement, and testing, notably: 


Specifying a more open on-board architecture standard for ATMS Il, leveraging the 
Connected Fleet Vehicles & Facilities project as a foundation. 


Requiring the selected ATMS II vendor to demonstrate multi-make and model compatibility 
for on-board equipment-- particularly the MDT and IVU/VLU given a specific operating 
system and functionality set. In addition, equipment compatibility should be demonstrated 
across the bus and rail fleets. 


Ensuring that open platform compatibility testing is conducted at multiple stages of the 
ATMS II deployment, and deploying multiple makes and models of key equipment elements. 
The goal is to ensure Metro does not become “stranded” with a non-industry standard 
device that cannot be easily transitioned to newer equipment. 


Work with the contractor to establish a “configuration baseline” with all of the necessary 
details to enter into, manage, and maintain configuration management for a minimum 
period of 10-15 years. 
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Long-term ATMS II Recommendations 


The following are some recommendations to be implemented in the future: 


e Re-examine communication options when 5G and 6G becomes available. 
e Replace or upgrade CAD system after 10 years. 
° Replace or upgrade all servers after 5 years. 


23 On-board Architecture 


Historically, on-board architectures have centered on one or more IVU/VLUs that offer proprietary 
integration to other devices (e.g., APCs, AVA, DVRs, etc.). This integration has been expensive and time 
consuming, and has often led to agencies effectively deploying multiple IVU/VLUs on a vehicle to avoid the 
integration costs. Changes in the mobile/automotive computing hardware and software market are 
starting to break down these proprietary barriers to integration. Where common public transit data 
standards may not exist, the consumer electronics and automotive original equipment manufacturers 
(OEM) industries are stepping in and “selecting de facto standards” for their own purposes. The benefits 
of these trends are starting to open up new possibilities for transit agencies looking to update/deploy new 
on-board equipment and update their architecture approaches. These trends look to a more open 
hardware environment, particularly for the IVU/VLU and MGR components on the vehicles, where 
integration and interfaces will not be a priority. The mobile data terminal (MDT) shifts to being a display 
device on the on-board Ethernet/IP network and the IVU/VLU becomes a platform running a selected 
operating system (OS) much like the competitive procurement environment for workstation and server 
hardware. Following this trend creates an architecture that is more open and allows agencies to more 
readily transition mobile hardware and components without being beholden to a single vendor. While not 
fully mature in the transit environment, outside forces in the mobile computing world are ensuring this 
trend is certain to continue. 


The following sections describe the recommendations for the bus and rail fleet on-board architectures. 
The table below provides an overview of the sequenced on-board architecture projects comprising the 
recommendations for both the bus and rail fleet solutions to best support the technology program 
outlined in this Plan, along with some key current/ongoing and planned projects impacting the on-board 
architecture recommendations. They also represent the best options for leveraging other solutions 
implemented under the program that will result in cost savings and reduced timelines for implementation. 
Note that some elements represent shared projects between bus and rail. The recommended projects and 
approach to implementation are described in greater detail in the following bus and rail fleet sections. 


ON-BOARD ARCHITECTURE FOR BUS AND RAIL FLEETS PLANNED AND RECOMMENDED PROJECTS SUMMARY 


0.2 Expand Router to 500 Vehicles Part of Connected Bus & Facilities efforts; its costs are not included in on-board 
(Connected Bus) architecture cost estimates, but included in existing projects and/or ATMS Il. 

0.3 Emerging Bus/Rail Architecture Early stages of agency planning and development of new on-board architecture — 
Planning/Requirements included in on-board architecture costs. Note this should be conducted cooperatively 


between bus and rail to establish which architecture elements should be common 
fleet-wide and which are bus or rail specific. 


0.4 Requirements for Early, more detailed planning and early implementation to ensure transitional stage 
New/Transitional On-Board for bus on-board architecture is consistent with what is established as part of project 


Architecture 


element 0.3. 
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0.5 Fleetwide MGR (and cellular 
data) for Bus 


Period of confirmation if project C.2 is moving forward or if the MGR and cellular data 
implementation will be part of the ATMS II implementation. Note that the timeline for 
C.2 and O.5 may vary, but the Connected Bus and Facility efforts are assumed to be in 
place by ATMS II or they would have to be combined into that project effort. 


0.6 Automated Passenger Counter 
(APC) Project 


It is anticipated that the APC systems on-board buses will be updated prior to the ATMS 
Il implementation. This means that APC replacement systems should demonstrate 
compatibility with the emerging trends architecture and the ability to communicate 
through the MGR. 


0.7 Fleetwide MGR (and cellular 
data) for Rail 


As part of the larger Connected Fleet Vehicles & Facilities project, rail vehicle would be 
receiving MGRs with associated cellular data and Wi-Fi connectivity. APC and VSS, as 
well as live video feeds would be supported through this component of the on-board 
architecture. 


0.8 Emerging Bus + Rail Architecture 
Implementation 


The actual implementation of the on-board architecture will occur as part of the ATMS 
ll implementation (A.5). 


0.10 On-Board Systems Configuration 
Management 


Once the on-board architecture is established and in implementation as part of ATMS 
ll, it is important to enter configuration management for the on-board architecture, 
requirements, and interfaces to ensure long-term effectiveness and consistency. 


0.11 Review & Refresh Bus + Rail On- 
Board Architecture 


By 2025 Metro should review the status of the on-board architecture and determined 
if any adjustments or changes are required. 


Three ranges of emerging on-board technology trends were evaluated for this Strategic Plan, including: 
current technology trends, emerging trends, and future trends. Given the timelines anticipated for the 
connected bus, ATMS Il, and related projects, the emerging trends was selected as the baseline for the 
new on-board Metro systems architecture. 


2.3.1 Bus Fleet On-board Architecture 


= 


This project sees the implementation of an emerging-trends based on-board architecture as part of the 
ATMS II project and as described in detail in the Implementation Considerations sub-section below. 


On-Board Systems Architecture — Bus (Emerging Trends) 


Projects ©2703, 0 405,015, 08,6 O10 


Benefits 


° Improved data communications with vehicle and updated on-board systems - including 
removal of MDT limitations. Easier future integration and swapping of on-board equipment. 


° A major advantage of this approach is that it allows Metro to transition, replace, and upgrade 
key on-board devices without proprietary hardware/interface limitations. 


e Strong potential for equipment and integration cost savings for minimal costs when 
compared with the costs of fleet-wide equipment/device replacements in combination with 
new central system integration. 


° Eliminates direct ties to a single vendor where Metro is unable to update on-board 
hardware/software without expending well above anticipated levels. 
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Technical Analysis Summary 
The emerging trends architecture was primarily recommended for the following reasons: 


e It is an excellent fit with Metro’s proposed Connected Fleet Vehicles & Facilities project 
efforts which would deploy Mobile Gateway Routers (MGRs) on the entire bus fleet. In 
addition, Metro’s latest bus procurement specification includes a substantially capable MGR 
requirement. These provide the foundational elements of the emerging trends architecture. 


e Metro’s stated desire is to be consistent with emerging technologies, but not to necessarily 
incur the risks of “bleeding edge developments” which tends to rule out the future trends 
architecture which is more fully device to device and Internet of Things (loT) based. This 
environment has not matured nearly to the same extent as the emerging trends 
architecture. 


e The emerging trends on-board architecture overcomes some of Metro’s past difficulties of 
integration to a single proprietary platform, including becoming locked into utilizing 
outmoded Mobile Data Terminals (MDTs) that cannot be replaced or upgrades without a 
complete system upgrade. 


e The emerging trends architecture provides a solid foundation to advance the state-of-the- 
fleet on-board as new functions and devices emerge over time through promotion of a 
common on-board Ethernet/IP network with a common MGR as a mobile communications 
platform that can evolve as communications needs and opportunities shift over time. 


The implementation section discusses more of the device by device implications on board the bus. 
Benchmarking 


The use of a MGR as a common communications platform on board the bus is now standard practice for 
new fleet system procurement efforts. On-board Ethernet/IP environments have been implemented by 
TriMet (Portland), RTD (Denver), AC Transit (Oakland), Foothill Transit (LA), and many others across North 
America. The extent of the individual device integration to the on-board Ethernet/IP environment varies 
by implementation, but frequently includes: MDTs, APCs, camera systems, IVUs/VLUs, and on-board 
customer information displays. Devices are starting to emerge that would support Ethernet/IP for vehicle 
health monitoring, headsign displays, etc. 


Cost Summary 


The costs of adopting the emerging trends on-board architecture is largely additive to the ATMS I! project 
in terms of increased architecture and configuration management costs in terms of agency staff support, 
increased testing and design costs for the initial ATMS II implementation efforts, and some minor costs for 
additional equipment/devices to test cross-compatibility between different IVUs and MDTs. 


CAPITAL COSTS O&M COSTS (10yr) 
S 2.4M* S 1.2M** 


*Over planning and implementation period for ATMS II 


**Costs mostly staff related for architecture and configuration management as new devices/systems emerge on board the 
vehicles. 


Additional cost break down information may be found in the ROM Section 5. 
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Assumptions 


e Metro will continue to move forward with its Connected Fleet Vehicles & Facilities project 
efforts, ultimately leading to all buses having MGR implementations (either through retrofits 
or new bus procurements). 


° The use of commercial cellular data or similar (e.g. LA RICS data) is assumed as LMR systems 
would be unable to adequately support the data communications loads envisioned from the 
MGR and other devices on the bus. 


e Metro will coordinate all new bus on-board device procurements to be consistent with the 
on-board architecture. This may require some additional planning and work up front, but 
will dramatically lower risks and costs over time as equipment ages, is replaced, or 
compatibility needs to be maintained as new vehicles are procured. 


Implementation Considerations 


There will be some key decisions to be made as the development and implementation of the on-board 
architecture proceeds: 


e It is not sufficient to standardize on an Ethernet/IP communications platform on-board. 
Metro will need to make more detailed architecture decisions such as the on-board IVU 
operating system. Individual on-board device applications may be integrated with the open 
IVU/VLU platform or run as an application on the IVU/VLU itself. The goal would be to allow 
multiple vendor applications to operate on the IVU/VLU without the need for proprietary 
integration efforts by the IVU/VLU vendor. This is similar to running different devices or 
applications on and connected to a typical PC computing platform. 


° Additional testing will be required to prove that the IVU/VLU and MDTs are truly an open 
platform and that the same ATMS II applications can run on multiple devices from different 
suppliers. While this may seem like unnecessary additional effort up-front, it helps to 
demonstrate the necessary flexibility of the on-board devices and helps ensure future 
compatibility and upgrade paths are retained. 


e The priority of devices and communications on-board the bus needs to be determined. 
Devices such as automated fare collection systems (including smart cards and mobile 
payments), camera systems, and data/voice communications are normally prioritized at the 
highest level through the MGR settings/configuration. 


° Metro will need to establish an on-board systems configuration management group(s) to 
deal with on-board network configuration, devices/settings, requirements for new 
procurements, and ensuring adjustments/changes don’t have unanticipated consequences. 

This group could include bus and rail agency staff in a combined configuration management 

effort. 


e The current pool of CAD/AVL vendors may be resistant to supplying a more open IVU/VLU 
and on-board architecture in an effort to maintain a single supplier proprietary relationship 
with Metro. However, a review of hardware and software development platforms in use by 
these vendors indicates that this goal should be more than achievable within the timeframe 
of the ATMS II planning and implementation. Just as consumers are no longer willing to 
accept smartphones that can only run apps from a single company, the transit industry 
should no longer accept |VUs/VLUs that are essentially proprietary devices. 
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Implementation Schedule and Key Dependencies 


The on-board bus architecture effort is strongly tied to the ATMS Il and the Connected Fleet Vehicles & 
Facilities projects. Initial architecture requirements must be confirmed and basic on-board configuration 
management put in place as part of ATMS II planning and procurement. The timeline below provides a 
snapshot of the recommended on-board bus architecture projects and related projects 


Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 


2016 2017 2018 2019 2020 2021 2022 2023 


(A.1, A.2, A.3, A.4, A.5) 


(C.2) Connected Vehicle: Establish (Commercial) Cellular Data (0.4) Requirements for New/Transitional Onboard Architecture 
Service For, Bus Fleet (0.5) Fleetwide MGR (and cellular data) for Bus 

(0.2) Expand Router for 500 vehicles (Connected Bus) (0.7) Fleetwide MGR (and cellular data) for Rail 

(0.3) Emerging Bus + Rail Architecture Planning/Requirements (0.8) Emerging Bus + Rail Architecture Implementation 

(AX) ATMS Il efforts:: (0.10) On-board Systems Configuration Management 

(A.1) Planning and Approvals: 10/2016 To 3/2017 (A.4) ATMS II Procurement: 7/2018 To 3/2019 

(A.2) Procurement of Project Support: 4/2017 To 12/2017 (A.5) ATMS II Implementation — Bus: 4/2019 To 8/2023 

(A.3) Preparation for Procurement: 1/2018 To 6/2018 (A.6) ATMS II Implementation — Rail: 4/2020 to 8/2023 
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The figures below display the recommended on-board architecture for the bus that is consistent with 
emerging trends in the transit industry. The first figure shows the onboard architecture of a bus with a 
transitional architecture. The second figure shows the recommended emerging trends on-board 


architecture. The table that follows the second figure discusses the architecture implications of each on- 
board device. 


Transition Stage Bus 
(Existing to Emerging) 


Key to On-Board Elements 


@ kxisting 
@ Replace / upgrade 


© New 


y 
1 
! 
1 
1 
1 
ry 


%* Only applies to New Flyer buses i 
(New Flyer Connect) 


11010011010 
[——sa8} 


IU /VLU 
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Emerging Bus 
Key to On-Board Elements 


«5 @ kxisting 
ans & Replace / upgrade 


& New 


@ Carry-over from transitional stage 


(5) 


DATA | CELL 


=> 
e 


WiFi 
PUBLIC 


am 


VOICE 
(voir) 


* 1 Open platform IVU 
* 2 Discretes tied to IVU: | 


- doors 

- ignition 

- bike rack (deploy/use) 
- odometer 

- silent alarm 

- other 


* 3 Potential retain voice radio as fall back 

* 4 Some potential V-I apps and IVU 

*5 Connected vehicle communications through on-board network 

* 6 OEM connected vehicle (safety/autonomy) functions on separate 
on-board network with alarms and data bridged to MGR network 


ON-BOARD DEVICE NOTES ON INTEGRATION INTO EMERGING ON-BOARD ARCHITECTURE 


Intelligent Vehicle In the emerging architecture, the IVU/VLU will remain a core on-board computing platform, but must be 
Unit/Vehicle Logic proven to be non-proprietary. The selected ATMS || vendor software must be capable of operating on 
Unit (IVU/VLU) multiple IVU/VLU devices from different manufacturers as well as being capable of running third party 


applications for other on-board devices (such as vehicle health monitoring, Bus Signal Priority, and possibly 
41010011010 others. Metro will need to select an operating system for the new IVU/VLU that will remain common 

|—— a8 regardless of the hardware utilized. The processing and capabilities of the |VU/VLU procured through ATMS 
VU / VLU || should allow for future growth and integration of other on-board devices over time. 
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ON-BOARD DEVICE NOTES ON INTEGRATION INTO EMERGING ON-BOARD ARCHITECTURE 


Mobile Data Terminal The emerging architecture calls for an MDT that is effectively a touch/input device with a multipurpose 


(MDT) 


LCD/similar display. Basic audio and auto light adjustments should also be in place. The MDT should be 
directly connected to the on-board Ethernet/IP network without separate or additional proprietary 
connections to the IVU/VLU. The goal is that the MDT should be able to be replaced (as partial fleet 
upgrades) without the need to upgrade or change the IVU/VLU. In addition, as part of the ATMS Il 
deployment, the vendor should be able to demonstrate at least three different MDT makes and models that 
can perform the necessary on-board functions. While this will require extra diligence and testing during the 
ATMS II deployment, it is critical as this has been a problematic area for Metro in the past where MDTs 
become difficult to maintain or replace. 


Automated Currently AVA and ASA functions are integrated with the IVU/VLU. This could remain the case for the new 
Video/Stop architecture and the ATMS Il implementation. However, a more open IVU/VLU should allow for independent 
Announcements AVA/ASA systems that are not necessarily tied to the primary ATMS II vendor. This also offers the opportunity 
(AVA/ASA) for ADA supporting functionality or improved AVA/ASA technology enhancements to be added over time 


mG) sto? 


AVA/ ASA 


leveraging the open IVU/VLU platform and the communications functionality of the MGR for both customer 
based (e.g. smartphone, ADA device) or on-board functions. 


Vehicle Health 
Monitoring (VHM) 


There is limited VHM functionality currently deployed (e.g. New Flyer Connect as an example) in the vehicle 
fleet and it is independent from other on-board systems. Enhanced VHM functionality and integration is 
highly desired and could be run on the open IVU/VLU platform with deployment either as part of ATMS II 
implementation or separately. The VHM communications should be integrated through the MGR for both 
Wi-Fi and mobile data. 


Vehicle Discrete 


VEHICLE 
DISCRETES 


For the foreseeable future and as part of the ATMS II implementation, some vehicle discretes will need to 
be maintained and integrated. For example, ignition status, bike rack deployment, ADA ramp deployment, 
etc. Discrete connections should be maintained separate from the IVU/VLU box to maintain the flexibility of 
swapping that device or updating over time. Discretes could be connected through backplanes or terminal 
blocks. Power down timers should be managed through the IVU/VLU or the MGR as derived from the ignition 
status. 


Bus Signal Priority 
(BSP) 


Bus Signal Priority is being integrated with the current ATMS IVU/VLU, and it is assumed that this 
functionality will be carried over to ATMS II when it is deployed. The major change would be that the BSP 
communications should ultimately be routed through the MGR either as Wi-Fi, DSRC, or other. 
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ON-BOARD DEVICE 


NOTES ON INTEGRATION INTO EMERGING ON-BOARD ARCHITECTURE 


Connected Vehicles 


Q: 


CONNECTED 
VEHICLE 


OEM 
CONNECTED 
VEHICLE 


At this point, the full range of Connected Vehicle functionality is not defined, but it will clearly impact the 
on-board bus architecture and related functionality in several areas. For the emerging on-board 
architecture, it is envisioned that CV applications will fall into three categories/areas: 


e = Original Equipment Manufacturer (OEM) Connected Vehicles — These are Autonomous Vehicle and 
Connected Vehicle functions that would be procured with new buses over time. These would largely 
be safety or guidance based functions that would be part of the vehicle manufacturer’s production, 
integration, and safety integrity level (SIL) assessments. While these systems might provide status or 
alerts to the remainder of the on-board architecture, for safety reasons they would largely remain 
independent from the remainder of on-board fleet systems. 


e Connected Vehicle Communications — Largely centered on Dedicated Short Range Communications 
(DSRC) in the 5.9GHz range. It is envisioned that these communications functions will ultimately be 
internal to or integrated with the MGR. Some specialized Autonomous Vehicle (AV) functions may 
retain separate DSRC communications. 


e Connected Vehicle Applications Running On-Board — In addition to the OEM and CV communications 
specific functionality, some CV functions call for on-board computing power and integration with 
other fleet management systems. These functions could be supported by the open IVU/VLU platform 
for options such as flex routing, shared ride coordination, or other Vehicle-Infrastructure CV 
applications. 


Automatic Vehicle 
Location (AVL) 


AVL functionality should be accurate enough to support all location needs on the bus and should be able to 
provide AVL data to all other on-board elements without the need for additional or separate GPS antennas 
or AVL systems. This can also serve as a common on-board time source. Sometimes AVL functionality is 
integrated into the MGR and/or the IVU/VLU, but in either event, the ability of it to provide common AVL 
data for the vehicle should be demonstrated. 


Mobile Gateway 
Router (MGR) 


The MGR would be provided through multiple means: new bus procurements, Connected Fleet Vehicles & 
Facilities project, and ultimately ATMS II if required. The MGR is the foundational element of the on-board 
architecture and serves to extend an IT/network type environment onto the bus. The MGR allows for 
multiple modes of communications, prioritization of communications, a single point for communications 
upgrades/adjustments, switching between various on-board communications options based on configurable 
rules, and an improved method of monitoring communications of the mobile fleet. The MGR usually is 
directly connected to some key devices as part of the on-board network, and a separate switch provides 
additional Ethernet ports (usually 8+). This means that priority devices must typically be connected to ports 
directly on the MGR or on a managed switch connected to the MGR. 


Ethernet/IP On-Board 
Connectivity 


As part of the Connected Fleet Vehicles & Facilities project, as well as ATMS II, the on-board bus architecture 
should move towards all devices being Ethernet/IP capable. All devices should be connected to the on-board 
network through the MGR or associated switches, and not directly to the IVU/VLU. Some specific discrete 
connections (such as ignition status, etc.) may be retained to the IVU/VLU, but these should be limited and 
reduced over time. 
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ON-BOARD DEVICE NOTES ON INTEGRATION INTO EMERGING ON-BOARD ARCHITECTURE 


Cellular Data The recommended data communications options for Metro is cellular data through either commercial 
LTE sources or LA-RICS. Cellular data communications serves as the primary means of mobile data 
((HH)) communications from the bus. The MGR should be capable of supporting either or even both data 

DATA 4 CELL communications networks. 


Voice The Communications Plan recommends VoIP communications as the primary voice communications means 
Communications for bus. VOIP can be setup for RTT/PRTT type communications methods used by the BOC. It is important to 
(VoIP with possible note that VOIP occurs over cellular data which is distinct from the cellular voice network which is more likely 
radio fallback) to become overloaded during emergency situations. VOIP functionality is most frequently implemented as 


a separate VOIP card or device on the bus which is integrated with the IVU/VLU and MDT to emulate the 
RTT/PRTT functionality. In some cases, VOIP functionality might be integrated with the IVU/VLU which 
should be carefully reviewed to ensure that this does not compromise the IVU/VLU as being an open 
platform moving forward. The existing voice radio system could be retained for fallback/redundancy 
purposes. The existing voice radio system could be converted to open talkgroups as fallback or integrated 
directly as a fallback solution with the VOIP controller. 


Wi-Fi Metro intends to provide public Wi-Fi access on some vehicles/routes and this is an element of the 
Communications Connected Fleet Vehicles and Facilities project that would deploy MGRs on bus and ultimately rail vehicles. 
(Agency & Public) In addition, the MGR will need to support agency Wi-Fi communications needs for the upload/download of 


data from various systems on-board the vehicles. Options for using cellular data for all of these functions 
were reviewed, but proved cost-prohibitive. All Wi-Fi communications should be routed through the MGR 
regardless of whether the on-board device is directly integrated with the IVU/VLU or not. 

WiFi 
PUBLIC 


Automated Passenger Metro intends that APCs will be replaced during the transitional stage of the on-board architecture, and may 
Counters (APCs) proceed the ATMS II implementation. This means that the APC sensors and analyzer will be independent of 
the IVU/VLU. To maintain architecture consistency and avoid potential integration issues down the road, 
APC logic should be deployed on an open platform with an on-board operating system consistent with the 
IVU/VLU operating system. This should leave the opportunity to move the APC applications and functionality 
to the IVU/VLU in the future should Metro desire to do so. 
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ON-BOARD DEVICE NOTES ON INTEGRATION INTO EMERGING ON-BOARD ARCHITECTURE 


Video Surveillance Currently Metro buses are deployed with a range of makes/models/ages of on-board surveillance systems. 
System (VSS) & Live As part of the emerging architecture, all VSS on-board fleet vehicles should be Ethernet/IP capable and be 
Video Feeds connected to the on-board network and MGR. Newer DVRs that are part of the VSS have 2TB of storage to 


support Metro video retention requirements. Ultimately, once the Connected Fleet Vehicles and Facilities 
projects are complete and the DIMS and video storage efforts done, it may not be necessary to maintain 
such substantial storage on-board the vehicles. All video (with sound) downloads, uploads, and live feed 
access should be communicated through the MGR with the MGR providing QoS and prioritization 
functionality. Only some Metro VSS are capable of live video feeds, but this should become a standard 
requirement for all new and replacement systems, as it was viewed as a high priority need. ATMS II costs 
include some % of VSS replacements on the existing fleet to meet this standard. It is not intended that the 
architecture support full time live video feeds from a large number of vehicles, and live feeds would be 
focused on emergency or special situations with a selected group of operations, security, and law 
enforcement staff having the ability to activate live feeds. 


I-See-U Monitor & Metro has had good success with providing a monitor on-board buses that demonstrates to passengers that 
Passenger Info Display security cameras are present on the bus and video is being recorded. These are known as “ICU” systems. 
For the emerging architecture, the ICU display should be part of the on-board Ethernet/IP network, although 
video feeds might stem directly from the DVR which is part of the VSS. In addition, the architecture supports 
a separate LCD or similar customer on-board information display that could obtain base data through yard 
downloads with lower bandwidth data updates through cellular. All of this would be conducted through the 
MGR. Also, the ICU and Info Display could be merged to displays on-board live video as well as traveler 
information such as service alerts, bus position/map, connecting status and anticipated arrival at key 


locations. 
Smart Drive SmartDrive is currently an independent system on Metro buses and rail vehicles. Its primary focus is for 
incident surveillance and risk management where certain G-forces and other situations trigger video saving 
| @., and download for basic on-board and outside front views. SmartDrive is highly valued by Metro for these 
functions and the ease of accessing the stored/tagged video. It will remain separate as part of the new on- 
SMART board architecture for the foreseeable future. 
DRIVE 
Farebox & Smartcard The on-board farebox and smart card (TAP) system are anticipated to receive updates over the life of the 
(TAP) new on-board architecture. Key to the TAP updates is the desire to allow account values and updates (such 


as new or recharged TAP cards) to be quickly recognized on the buses. Currently these changes may take 2- 
3 days to appear. The new on-board architecture assumes updated communications will be integrated from 
the smart card through the MGR cellular data connection. It should be possible to support desired security 
without a separate independent cellular connection. The actual software/configuration changes for TAP 
would be part of a separate project effort. This connection between the smartcard and the MGR/cellular 
communications could occur during the transitional stage (after the MGR/Connected Fleet Vehicle projects 
but prior to full ATMS II implementation). Ultimately, should a farebox/smartcard be retained in the longer- 
term, the separate wireless communications should be integrated through the MGR. 
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2.3.2 Rail Fleet On-board Architecture (Emerging Trends) 


The recommended rail on-board architecture included some unique elements due to the diverse 
character of the systems and level of integration of the existing Metro vehicle fleet. As with bus, three 
ranges of emerging on-board technology trends were evaluated for this Strategic Plan, including: current 
technology trends, emerging trends, and future trends. The desire was to establish some elements of 
fleet-wide commonality for the on-board architecture while recognizing the elements unique to rail, as 
well as the role track wayside and SCADA systems play in managing and controlling rail operations. The 
goal was for the on-board rail architecture to establish some commonality for like elements, but 
supplement or support existing track wayside and rail control systems rather than replace them over time 
(as was the case with bus elements). As part of the Strategic Plan program elements, rail vehicles could 
receive the initial MGR and cellular data connectivity through the Connected Fleet Vehicles and Facility 
project and/or as part of ATMS Il. 


Currently, the rail vehicles lack consistent on-board device integration for VSS/DVR, Wi-Fi connectivity, 
AVA/ASA, and APC where these exist. Individual systems are often procured with the rail vehicles 
themselves or outfitted at the time the rail line is implemented. Several rail vehicles have unique train 
separation/spacing control systems that work in conjunction with the track wayside communications. 


While some elements of rail on-board architectures remain unique to the make and model of the rail 
vehicle, many other supplemental communications and customer information elements can be part of the 
broader on-board fleet vehicle architecture. For Metro, the advantage rail vehicles have in updating the 
on-board architecture, is that they are not as subject to the past decisions and existing systems as rail 
technologies have tended to be track-to-wayside based with limited on-board equipment. The common 
fleet on-board architecture elements for rail vehicles would include: MGR with Wi-Fi and cellular data 
communications, VSS/live video, passenger info displays, \VWU/VLU, and MDT. Other train specific elements 
would remain independent of the new on-board architecture such as train protection (ATP), rail worker 
safety (ProTran), rail voice radio, track wayside (TWC), smart drive, and rail specific traction, power and 
related systems. Some agencies are looking at methods to use newer on-board communications and 
architectures (as recommended in this Plan) to provide key train system alerts from braking, power 
traction, and power management subsystems. As with the bus architecture, the emerging on-board 
architecture for rail looks to a more open hardware environment, particularly for the IVU/VLU and MGR 
components on the vehicles, where integration and interfaces will not be a priority. The mobile data 
terminal (MDT) shifts to being a display device on the on-board Ethernet/IP network and the IVU/VLU 
becomes a platform running a selected operating system (OS) much like the competitive procurement 
environment for workstation and server hardware. Following this trend creates an architecture that is 
more open and allows agencies to more readily transition mobile hardware and components without 
being beholden to a single vendor. While not fully mature in the transit environment, outside forces in the 
mobile computing world are ensuring this trend is certain to continue. 


On-Board Systems Architecture — Rail (Emerging Trends) 


Projects: 0.3, 0.4, 0.5, 0.7, 0.8, & 0.10 
For this project, Metro will implement the emerging trends-based on-board architecture as described in 


greater detail in the Implementation Considerations sub-section below. This will follow the same sequence 
as described in the on-board architecture section introduction. 
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Benefits 


° Improved data communications with vehicle and updated on-board systems. Easier future 
integration and swapping of on-board equipment. 


° A major advantage of this approach is to allow Metro to transition, replace, and upgrade key 
on-board devices without proprietary hardware/interface limitations. 


° Commonality between some on-board elements and the architecture of the bus and rail 
vehicle fleets will result in economies of scale and simplify future upgrade paths, as well as 
support easier back office integration of rail and bus data for customer information and 
operations applications. 


e Strong potential for equipment and integration cost savings for minimal costs when 
compared with the costs of fleet-wide equipment/device replacements in combination with 
new central system integration. 


° Eliminates direct ties to a single vendor where Metro is unable to update on-board 
hardware/software without expending well above anticipated levels. 


Technical Analysis Summary 
The emerging trends architecture was primarily recommended for the following reasons: 


e It is an excellent fit with Metro’s proposed Connected Fleet Vehicles & Facilities project 
efforts which would deploy Mobile Gateway Routers (MGRs) on the entire rail. Rail vehicles 
turn-over far less frequently than buses, which means that retrofits are much more likely 
than simply capturing the new architecture in vehicle turn-over. 


e Metro’s stated desire is to be consistent with emerging technologies, but not to necessarily 
incur the risks of “bleeding edge developments” which tends to rule out the future trends 
architecture which is more fully device to device and Internet of Things (loT) based. This 
environment has not matured nearly to the same extent as the emerging trends 
architecture. 


e The emerging trends on-board architecture for rail vehicles allows for Metro to much more 
cost-effectively implement rail specific functionality using the open IVU/VLU platform, MGR 
communications, and the MDT. Proper implementation of this architecture as part of ATMS 
Il will support future rail functional enhancements without being tied to a specific vendor. 


e The emerging trends architecture provides a solid foundation to advance the state-of-the- 
fleet on-board as new functions and devices emerge over time through promotion of a 
common on-board Ethernet/IP network with a common MGR as a mobile communications 
platform that can evolve as communications needs and opportunities shift over time. 


The implementation section discusses more of the device by device implications on board rail vehicles. 
Benchmarking 


While the use of a MGR as acommon communications platform on board the bus is now standard 
practice for new fleet system procurement efforts, it is just now becoming more common on rail vehicles. 
Early implementation of MGRs on rail vehicles have been used to provide enhanced GPS/communications 
for rail arrival prediction and customer information applications. MBTA implemented a “rail hardened 
MGR” on their Green Line rail vehicles for enhanced rail vehicle positioning and schedule arrival 
prediction. TriMet recently initiated a procurement for a Mobile loT Gateway specification to support a 
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variety of rail specific functions including on-board schedule adherence displays, arrival prediction 
improvements, and enhanced rail controller/operator text communications (the advantage of text 
communications through a rail MDT is that it can remain inactive/inaccessible when the vehicle is in 
motion). 


Cost Summary 


Rail vehicle inclusion is an option as part of ATMS Il. Therefore, the costs of adopting the emerging trends 
on-board architecture is largely additive to the ATMS II project in terms of: increased architecture and 
configuration management costs in terms of agency staff support, increased testing and design costs for 
the initial ATMS Il implementation efforts and some minor costs for additional equipment/devices to test 
cross-compatibility between different IVUs and MDTs. 


CAPITAL COSTS O&M COSTS (10yr) 
$ 1.2M* S 874K** 


*During the planning and implementation period for ATMS II 


**Costs mostly staff related for architecture and configuration management as new devices/systems emerge on 
board the vehicles. 


Additional cost break down information may be found in the ROM Section 5. 
Assumptions 


e Metro will continue to move forward with its Connected Fleet Vehicle & Facilities project 
efforts, ultimately leading to all rail vehicles having MGR implementations (either through 
retrofits or new bus procurements). 


° The use of commercial cellular data or similar (e.g. LA RICS data) is assumed as LMR systems 
would be unable to adequately support the data communications loads envisioned from the 
MGR and other devices on the rail vehicle. As part of the communications plan, FluidMesh 
and other options were reviewed and seemed to offer some potential. Any such solution 
should be integrated with the on-board architecture through the MGR. 


° Metro will coordinate all new rail on-board device procurements to be consistent with the 
on-board architecture. This may require some additional planning work up front, but will 
dramatically lower risks and costs over time as equipment ages and is replaced, or 
compatibility needs to be maintained as new vehicles are procured. 


Implementation Considerations 


There will be some key decisions to be made as the development and implementation of the on-board 
architecture proceeds: 


e It is not sufficient to standardize on an Ethernet/IP communications platform on-board. 
Metro will need to make more detailed architecture decisions, including the on-board IVU 
operating system. Individual on-board device applications may be integrated with the open 
IVU/VLU platform or run as an application on the IVU/VLU itself. The goal would be to allow 
multiple vendor applications to operate on the IVU/VLU without the need for proprietary 
integration efforts by the IVU/VLU vendor. This is similar to running different devices or 
applications on and connected to a typical PC computing platform. 
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° The recommended on-board architecture opens up several opportunities to integrate or 
enhance rail specific functionality. This could include communications across train consists, 
yard management functions, and specific rail operations support functions. Metro should 
consider implementing at least one of these rail specific functions as a separate effort from 
ATMS II procurement as a proof of concept for the open IVU/VLU platform. 


° Additional testing will be required to prove that the IVU/VLU and MDTs are truly an open 
platform and that the same ATMS II applications can run on multiple devices from different 
suppliers. While this may seem like unnecessary additional effort up-front, it helps to 
demonstrate the necessary flexibility of the on-board devices and helps ensure future 
compatibility and upgrade paths are retained. 


° The priority of devices and communications on-board the rail vehicle needs to be worked 
out. Usually devices such as smartcards, camera systems, and data/voice communications 
are prioritized at the highest level through the MGR settings/configuration. 


° Metro will need to establish an on-board systems configuration management group(s) to 
deal with on-board network configuration, devices/settings, requirements for new 
procurements, and ensuring adjustments/changes don’t have unanticipated consequences. 

This group could include bus and rail agency staff in a combined configuration management 

effort. 


° The current pool of fleet system vendors may be resistant to supplying a more open 
IVU/VLU and on-board architecture in an effort to maintain a single supplier proprietary 
relationship, but a review of hardware and software development platforms in use by these 
vendors indicates that this goal should be more than achievable within the timeframe of the 
ATMS II planning and implementation. Just as consumers are no longer willing to accept 
smartphones that can only run apps from a single company, the transit industry should no 
longer accept IVUs/VLUs that are essentially fully proprietary devices. 


Implementation Schedule and Key Dependencies 


The on-board rail architecture effort is strongly tied to the ATMS II and Connected Fleet Vehicle & 
Facilities projects. Initial architecture requirements must be confirmed and basic on-board configuration 
management put in place as part of ATMS II planning and procurement. The timeline below provides a 
snapshot of the on-board rail architecture elements, as well as some related project efforts. 
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Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 


2016 2017 2018 2019 2020 2021 2022 2023 


(A.1, A.2, A.3, A.4, + A.5) 


(C.5) Connected Vehicle: Establish (Commercial) Cellular Data (0.5) Fleetwide MGR (and cellular data) for Bus 


Dervic HOF RallFleet (0.7) Fleetwide MGR (and cellular data) for Rail 


(0.3) Emerging Bus + Rail Architecture Planning/Requirements (0.8) Emerging Bus + Rail Architecture Implementation 


(0.4) Requirements for New/Transitional Onboard Architecture (0.10) On-board Systems Configuration Management 


(A.X) ATMS II efforts:: 


(A.1) Planning and Approvals: 10/2016 To 3/2017 (A.4) ATMS Il Procurement: 7/2018 To 3/2019 
(A.2) Procurement of Project Support: 4/2017 To 12/2017 (A.5) ATMS II Implementation — Bus: 4/2019 To 8/2023 
(A.3) Preparation for Procurement: 1/2018 To 6/2018 (A.6) ATMS II Implementation — Rail: 4/2020 to 8/2023 


The figure below displays the recommended emerging trends on-board architecture that is consistent 
with emerging trends in the transit industry. The table that follows the figure discusses the architecture 
implications of each on-board device. 
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TRAN 


ON-BOARD DEVICE NOTES ON INTEGRATION INTO EMERGING ON-BOARD ARCHITECTURE 


Intelligent Vehicle In the emerging architecture IVU/VLU will remain a core on-board computing platform, but must be proven 
Unit/Vehicle Logic to be non-proprietary with the selected ATMS II vendor software capable of operating on multiple IVU/VLU 
Unit (IVU/VLU) devices from different manufacturers as well as being capable of running third party applications for other 
on-board devices (such as vehicle health monitoring, Transit Signal Priority, and possibly others. Metro will 

11010011010 need to select an operating system for the new IVU/VLU that will remain common regardless of the 
|——s a5 hardware utilized. The processing and capabilities of the IVU/VLU procured through ATMS II should allow 

IVU / VLU for future growth and integration of other on-board devices over time. 

Mobile Data Terminal The emerging architecture calls for an MDT that is effectively a touch/input device with a multipurpose 
(MDT) LCD/similar display. Basic audio and auto light adjustments should also be in place. The MDT should be 


directly connected to the on-board Ethernet/IP network without separate or additional proprietary 
connections to the IVU/VLU. The goal is that the MDT should be able to be replaced (as partial fleet 
upgrades) without the need to upgrade or change the IVU/VLU. In addition, as part of the ATMS Il 
deployment, the vendor should be able to demonstrate at least three different MDT makes and models that 
can perform the necessary on-board functions. While this will require extra diligence and testing during the 
ATMS II deployment, it is critical as this has been a problematic area for Metro in the past where MDTs 
SCHEDULE TERE become difficult to maintain or replace. For the rail vehicles, the MDT would bring enhanced functionality 
including schedule adherence display (based on back-end rail location and prediction data), 
controller/operator text messaging, and vehicle status alerts. 
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ON-BOARD DEVICE NOTES ON INTEGRATION INTO EMERGING ON-BOARD ARCHITECTURE 


Automated Video/ 
Stop Announcements 
(AVA/ASA) 


mG) stor 


AVA/ ASA 


AVA and ASA systems are largely unique to each line and this makes updates difficult in a rapidly shifting 
technology world. The new architecture would standardize and update these functions, allowing fleet-wide 
enhancements without the need for wholesale equipment replacement. 


Vehicle Health 
Monitoring (VHM) 


VHM data on rail vehicles is difficult to obtain and requires extensive manual processes. The new on-board 
architecture would support enhanced rail specific VHM functions through the IVU/VLU and communications 
through the MGR to yard and rail maintenance and reporting systems. Key alerts on on-board devices, as 
well as rail specific system alerts (where available) could be integrated into this platform. 


Bus Signal Priority 
(BSP) 


Bus Signal Priority is being integrated with the current ATMS IVU/VLU, and it is assumed that this 
functionality will be carried over to ATMS II when it is deployed. The major change would be that the BSP 
communications should ultimately be routed through the MGR either as Wi-Fi, DSRC, or other. It is 
envisioned that this functionality could be implemented for some rail vehicles similar to what is planned for 
buses. 


Connected Vehicles 


— 


fxs 


4M 
CONNECTED 
VEHICLE 


At this point, the full range of Connected Vehicle functionality is not defined, but it will clearly impact the 
on-board bus architecture and related functionality in several areas. For the emerging on-board architecture 
on rail vehicles, this might include safety functions and customer information supporting functions, as well 
as others. The connected vehicle functions could be integrated into the |VU/VLU and communicated through 
the MGR or DSRC. 


Automatic Vehicle 
Location (AVL) 


AVL functionality should be accurate enough to supplement rail vehicle location data combined with the 
TWC and SCADA systems. 


Mobile Gateway 
Router (MGR) 


The MGR would be provided through multiple means: new rail vehicle procurements, Connected Fleet 
Vehicles & Facilities project, and ultimately ATMS II if required. The MGR is the foundational element of the 
on-board architecture and serves to extend an IT/network type environment onto the rail vehicle. The MGR 
allows for multiple modes of communications, prioritization of communications, a single point for 
communications upgrades/adjustments, switching between various on-board communications options 
based on configurable rules, and an improved method of monitoring communications of the mobile fleet. 
The MGR usually is directly connected to some key devices as part of the on-board network, and a separate 
switch provides additional Ethernet ports (usually 8+). This means that priority devices must typically be 
connected to ports directly on the MGR or on a managed switch connected to the MGR. 
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ON-BOARD DEVICE 


NOTES ON INTEGRATION INTO EMERGING ON-BOARD ARCHITECTURE 


Alerts & On-Board 
Train Systems 
Integration 


The new on-board architecture offers the opportunity to integrate key “operational impacting” alerts into a 
more robust and widespread communications platform. These alerts could be immediately sent to rail 
operators (via MDT), rail controllers, maintenance personnel, and others as needed. These alerts could also 
be stored and integrated with yard and maintenance management systems through the new on-board 
architecture. Siemens is offering an integrated on-board train systems management and alerting unit that is 
an example of a device that could provide alerts through the new on-board architecture. Other examples 
would become available as newer rail vehicles are procured or updated. It should be noted that in the 
architecture, this connection is shown as “future” and would probably not be viable or cost-effective for the 
oldest rail vehicles in the Metro fleet. 


Ethernet/IP On-Board 


Connectivity 


As part of the Connected Fleet Vehicles & Facilities project, as well as ATMS II, the on-board bus architecture 
should move towards all devices being Ethernet/IP capable. All devices should be connected to the on-board 
network through the MGR or associated switches, and not directly to the IVU/VLU. Some specific discrete 
connections (such as ignition status, etc.) may be retained to the IVU/VLU, but these should be limited and 
reduced over time. 


Cellular Data 
LTE 


(CD) 


DATA § CELL 


The recommended data communication options for Metro is cellular data through either commercial 
sources or LARICS. Cellular data communication serves as the primary means of mobile data communication 
from the rail vehicle. The MGR should be capable of supporting either or even both data communication 
networks. 


Voice 
Communications 
(remains separate) 


The Communications Plan recommends rail voice communications would remain as a separate system 
independent from the rest of the on-board architecture. This system was recently updated and can be 
expanded to support rail fleet expansion over the lifespan of the Strategic Plan. 


Wi-Fi 
Communications 
(Agency & Public) 


Metro intends to provide public Wi-Fi access on some vehicles/routes and this is an element of the 
Connected Fleet Vehicles and Facilities project that would deploy MGRs on rail vehicles. In addition, the 
MGR will need to support agency Wi-Fi communications needs for the upload/download of data from 
various systems on-board the vehicles. Options for using cellular data for all of these functions were 
reviewed, but proved cost-prohibitive. All Wi-Fi communications should be routed through the MGR 
regardless of whether the on-board device is directly integrated with the IVU/VLU or not. 
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ON-BOARD DEVICE NOTES ON INTEGRATION INTO EMERGING ON-BOARD ARCHITECTURE 


Automated Passenger 
Counters (APCs) 


For rail vehicle APC sensors and analyzers could be integrated with the IVU/VLU as part of ATMS Il. To 
maintain architecture consistency and avoid potential integration issues down the road, APC logic should be 
deployed on an open platform with an on-board operating system consistent with the IVU/VLU operating 
system. 


Video Surveillance 
System (VSS) & Live 
Video Feeds 


Currently Metro rail vehicles are deployed with a range of makes/models/ages of on-board surveillance 
systems. As part of the emerging architecture, all VSS on-board fleet vehicles should be Ethernet/IP capable 
and be connected to the on-board network and MGR. Newer DVRs that are part of the VSS have 2TB of 
storage to support Metro video retention requirements. Ultimately, once the Connected Fleet Vehicles and 
Facilities projects are complete and the DIMS and video storage efforts done, it may not be necessary to 
maintain such substantial storage on-board the vehicles. All video (with sound) downloads, uploads, and live 
feed access should be communicated through the MGR with the MGR providing QoS and prioritization 
functionality. Only some Metro VSS are capable of live video feeds, but this should become a standard 
requirement for all new and replacement systems, as it was viewed as a high priority need. ATMS II costs 
include some % of VSS replacements on the existing fleet to meet this standard. It is not intended that the 
architecture support full time live video feeds from a large number of vehicles, and live feeds would be 
focused on emergency or special situations with a selected group of operations, security, and law 
enforcement staff having the ability to activate live feeds. 


Info Display 


The on-board architecture can be integrated with the newer rail vehicle enhanced passenger information 
displays. This platform should be standardized over time and deployed common across all rail vehicles 
regardless of make/model/age. This is a major advantage of bringing the new architecture to rail vehicles, in 
that a wide variety of information and changes over time can be supported for customer information 
systems on-board. 


Smart Drive 


|e. 


SMART 
DRIVE 


SmartDrive is currently an independent system on some Metro rail vehicles. Its primary focus is for incident 
surveillance and risk management where situations trigger video saving and download for basic on-board 
and outside front views. SmartDrive is highly valued by Metro for these functions and the ease of access the 
stored/tagged video. It will remain separate as part of the new on-board architecture for the foreseeable 
future. 


Independent Rail 
Systems/Elements 


PRO 
TRAN 
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In addition to the voice radio, the on-board architecture would not seek to integrate some very specialized 
and often line specific rail elements, including track wayside functions, ProTran rail worker safety alert, and 
train protection separation/systems. In fact, it is generally preferable to leave train safety/separation and 
track wayside components separate from the more broadly accessible elements of the on-board 
architecture supporting communications through the MGR. 
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3 Supporting Systems 


Supporting systems are those elements of the 
technology program that further support operational 
efficiencies and overall cost reduction through the 
implementation of common platforms and single- 
sources of information along with improved ease of 
use for Metro staff interacting with the systems. 
Supporting systems have been grouped by major 
technology area and include traveler information, 
SCADA, video, and yard management. Some of the recommended projects in these categories build upon 
the improvements achieved from the foundational elements, such as leveraging the improved data 
sources from the ATMS I! implementation for traveler information or the ability to support real-time on- 
board video streaming through the improved data throughput achieved in the data communications 
projects. 


This section describes elements of the 
Strategic Plan technology program that 
support improved operations and customer 
experience today, and better prepare Metro 
for future technology solutions. 


Cpa Traveler Information Systems 


Like passengers of all transit agencies, Metro passengers expect accurate and timely traveler information 
including trip planning, vehicle locations, arrival/departure predictions, and service alerts at all stages of 
their journey; through a variety of media including on the agency website, electronic signs in stations, and 
third-party apps and websites created by developers. Metro aims to meet these expectations and provide 
high-quality real-time passenger information for its passengers. 


In the past decade, Metro has invested significantly in advanced traveler information systems for bus and 
rail, including successful efforts with enhanced trip planners, developer information portals, and customer 
information systems. However, a considerable number of work remains to improve the quality of the 
information provided to travelers and the consistency of information that is provided to bus and rail 
passengers. 


Through interviews with agency staff, clear needs were identified related to the improvement of the 
quality of real-time location reporting and prediction information for bus and rail passengers, more 
consistency of the information provided to bus and rail passengers, improved incorporation of service 
adjustments/alerts into traveler information feeds, and consolidation of traveler information 
dissemination on electronic information signs. 


The strategic plan recommends a set of projects categorized into the three overarching initiatives to help 
Metro meet these needs and greatly improve customer experience: 


° Rail vehicle locations and arrival predictions 
° Multi-modal systems, including service alerts 
e Customer-facing systems 


Note: improvements to vehicle locations and arrival predictions for bus are covered in the data 
communications and ATMS II project descriptions. 


Rail Vehicle Locations and Arrival Predictions 


The need to improve rail vehicle location information and arrival predictions was identified as critical to 
improve both operations and the customer experience. This need will be met by the implementation of a 
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series of separate phased projects described below. While Metro currently uses NextBus to make 
predictions for rail vehicle arrivals, the prediction engine used is the same as the engine used for bus 
arrival predictions. Using a bus arrival prediction engine for rail vehicles can result in accuracy issues as rail 
vehicles tend to behave differently from buses due to the nature of rail travel. For instance rail vehicles 
are unable to pass each other on a single track (or route) and trains must maintain longer, safer minimum 
following distances. 


The recommended projects are necessary in order for Metro to operate a refreshed and more robust 
multi-modal alerts system that expands on the agency’s existing real-time passenger information platform 
to provide the more accurate and timely rail vehicle location data and arrival predictions. The following 
recommended, sequenced projects offer best practice solutions with a risk-averse approach to future 
proofing. 


GPS + Track Wayside Circuits (TWC) and Beacons for Rail Vehicle 


Locations 
Project: T.4 


This project deploys the additional devices necessary on rail vehicles, 
at platforms/stations, and along the track, as needed, to support 
improved rail vehicle location and arrival predictions. Roof mounted 
GPS units are to be installed on trains for the above ground tracking 
vehicle locations in real-time. The GPS data is augmented with 
existing and track circuits that will be added where possible and 
where wireless beacons are not possible. The combination of TWC 
and beacon data gives improved rail vehicle location information for 
arrivals and departures at stations, and GPS data gives improved rail 
vehicle location while between stations. While the current vehicle 
location systems largely meet operational needs, this additional level 
of vehicle location granularity is necessary to provide more accurate — Example of Track Beacon Hardware 
and timely rail arrival predictions for customer information 


platforms. 

Benefits 

e Improved vehicle location accuracy results in more accurate time of arrival predictions. 

e More accurate time of arrival predictions will improve customer satisfaction with traveler 


information system. 
e Minimized costs through leveraging of existing hardware with cost-effective hardware to fill 
gaps. 


Technical Analysis Summary 


The deployment of extensive additional track wayside circuits (TWC) will be costly, and the deployment of 
multiple location devices will result in separate maintenance and operation requirements. Through the 
use of a blend of rail vehicle location equipment, including existing TWCs and more cost-effective GPS and 
beacon hardware, Metro will see a simultaneous reduction in implementation costs and an increase in 
location accuracy across its rail lines. 
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Once this solution is implemented, the SCADA system will no longer be single provider for rail vehicle 
location information, unless the GPS and beacon info is brought into SCADA. 


(Note that a cost-benefit analysis will still be necessary to determine where TWCs and beacons would best 
be deployed.) 


Benchmarking 


MBTA (Boston) uses a combination of track circuits, GPS, and TWCs on its Green Line light rail. RTD will use 
track circuits and TWCs, and is considering GPS in the future. No implementation of beacons in 
combination with other sources is known at this point. 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 
$ 2.8M S 940K 


Additional cost break down information may be found in the ROM Section 5. 


Capital and O&M costs could be reduced if GPS capability captured under Connected Vehicle or ATMS II deployments. 


Assumptions 


e ATMS II AVL features for rail will also be implemented to improve rail vehicle location 
reporting. 
e Implementation of a cellular data network for rail. 


Implementation Considerations 


Implementation of a cellular data network for rail will need to be implemented earlier or in conjunction 
with this project. 


Implementation Schedule and Key Dependencies 


At the time of this plan, Metro plans to move forward with the Connected Vehicle project, which will 
include mounting of separate GPS units on rail vehicles. These GPS units are necessary for improving rail 
vehicle locations and arrival time predictions augmenting the track wayside circuits. Costs of these GPS 
devices are included in project T.4; however, cost for T.4 may ultimately be reduced if the Connected Rail 
project is completed or if the work is rolled into the ATMS II project (A.5+A.5i). 


T.4 must be in progress, at a minimum, in order to move forward with the Rail-specific Prediction Engines 
project (T.5), which is covered in the next section. 


Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 
2016 2017 2018 2019 2020 2021 2022 2023 
(T.5) 


(T.4) GPS + Track Circuits and Beacons for Rail Vehicle Locations 


(T.5) Rail-specific Prediction Engine 
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Rail-specific Prediction Engine 


Project: T.5 


Metro develops a stand-alone arrival prediction engine specifically for rail vehicles that expands Metro’s 
rail prediction capability beyond what is currently available through NextBus. This prediction engine would 
be able to handle the specific rules and characteristics of rail vehicle travel. Potential features include: 


e Trains cannot pass each other. e Account for unscheduled out of 
P Pee service trains 
e Trains have to maintain safe 
separation. e Account for unscheduled extra 
ae service trains 
° Improved predictions when 
there are delays e Account for trains operating ona 
different route/branch than 
° Account for short-turns, 
é ; : scheduled 
diversions, bus bridges 
° Remove predictions for trains that 


° Account for terminal 


‘ move to an out-of-service location 
operations/turnaround 


(yard, storage track, etc.) 


Benefits 


e Improved prediction accuracy improves passenger confidence in Metro system and 
improves passenger's travel experience. 


° Provides Metro with additional rail arrival prediction capabilities; no longer limiting the 
agency only to NextBus availability, functionality, and features. 


Technical Analysis Summary 


Massachusetts Bay 
Transportation Authority 


This solution can be designed and developed so the 
core prediction engine system takes into account the 
operating realities and special cases of each Metro 
line. The custom software development will require 
integration with SCADA, ATMS II, and the hardware 
implemented during the Track Wayside Circuits and 
Beacons Project T.4, to incorporate improved vehicle cited aaa a Ae AEe 
location information. This will require some 
modifications to the existing SCADA software. This 
solution will minimize latency between prediction 
engine output and downstream users (e.g., website, 
traveler information signs, GTFS-realtime, API, etc.), 
and allow Metro to choose to pursue a solution that 
does not require ongoing Software as a Service (SaaS) 
costs. 


Realtime Rail | Reattime subway | Reattime Bus | Green Line Live Map 


Popular + | South Station 


SOUTH STATION 
Train Departures as of 10:03 AM 


Example of Real-time Passenger Information Available with 
a Rail-specific Prediction Engine 
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Benchmarking 


Rail-specific prediction engines are currently implemented or planned at MBTA (Boston), CTA (Chicago), 
WMATA (Washington DC), RTD (Denver) and BART (San Francisco Bay Area). 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 
S 562K S 536K 


Additional cost break down information may be found in the ROM Section 5. 


Assumptions 


Data from all rail vehicle location technologies (TWCs, beacons, and GPS) would be utilized in the 
prediction algorithm. 


Implementation Considerations 
Implementation Schedule and Key Dependencies 


Building on Project T.4, this prediction engine would utilize the additional rail vehicle data provided by 
Project T.4 to improve real-time rail vehicle information disseminated directly to customers and customer 


service representatives. 


Project T.5 must be in progress in order to complete the Multi-modal Alerts System project (T.3) because 
the alert system will ultimately pull data from this engine, as well as the enhanced data aggregation 
system (T.6) discussed below that will help improve Metro operations through the provision of better 
information to bus and rail controllers and customer service representatives. 


Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year & 


2017 2018 2019 2020 2021 2022 2023 


(T3) 


(T.3) Multi-modal Alerts 


(T.5) Rail-specific Prediction Engine 


(T.6) Enhanced Multi-modal Real-time Aggregation System + Single GTFS-realtime Feed 
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Multi-modal Systems and Service Alerts 


A key challenge for accurate and consistent traveler information is © Metro 
maintaining data quality across systems. Whenever data is passed 
between systems and subject to different rules or identifiers, 
inconsistencies can arise. This is especially true where external 
systems such as NextBus, Google, and other third-party 
applications are gathering information from separate locations. 
Minimizing data sources and developing a single source for open 
Metro data is the recommended solution to reduce the 
opportunity for the dissemination of inconsistent data to the 
public. Furthermore, conveying information to customers during 
service changes and disruptions is a vital tool to improve the 
transit customer’s travel experience. While Metro has made 
investments in RSS and Twitter feeds for sharing alerts 
information, Metro stakeholders identified the need for a unified 
alerts interface for bus and rail that is capable of sharing system 
information to customers during service changes and disruptions, 
e.g. detours, bus bridges, etc. 


Developer 


To best take advantage of national transit apps including Google 
Maps, RideScout and the talents of local developers, it is important 
to provide transit information to the public in standardized 
formats. While Metro provides schedule data through GTFS and 
arrival information through the NextBus API, a need was identified \nineenedl Riera Soniauia Help Banat 

to provide data through the GTFS-realtime standard. GTFS- Accurate Information on Multiple Platforms 
realtime leverages the existing GTFS schedule data by providing 

incremental updates where transit predictions are available. The 

consistency between the GTFS and GTFS-realtime datasets increases the utility and accuracy of websites 
and apps that use these data—directly improving customer information. 


To directly address these needs, the following sequenced projects build on completed work to improve 
rail vehicle location and arrival prediction. They will help meet the core goal of providing better quality 
information to customers and thereby increasing their trust (and use) of Metro services. 


Multi-modal Alerts System 


Project: T.3 


Metro implements a new system to enter, manage, and disseminate alerts with a focus on streamlining 
the alert creation process and disseminates the alerts via multiple channels. By implementing a more 
effective and accurate alert system, Metro would improve the accuracy and timeliness of its real-time 
passenger information systems; providing better information to customers, allowing them to make more 
informed travel decisions, and generally improving their experience with and confidence in Metro’s 
services. This system would provide the platform through which alerts are entered into the real-time 
passenger information platform, and, as such, should be underway prior to other data aggregation and 
improvement projects. 
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Benefits 
° More effective alert system allows passengers to make more informed decisions and 
improves the passenger's transit experience. 


e Potential costs savings through a single system solution through reductions in staffing and 
ongoing software system maintenance costs. 


° Single source for traveler information alerts simplifies system interfaces 


Technical Analysis Summary 


This solution allows for system-wide (bus and rail) alerts to be created in a single location, along with one 
system for external systems and apps to retrieve alerts information. A single system reduces total 
operation and maintenance requirements in part by reducing the number of staff required to operate the 
system. This will require internal coordination to maintain user privileges to allow appropriate access for 
staff. 


This solution can be implemented separately from ATMS || if Metro would like to move forward more 
quickly with the traveler information systems program described in this plan, or there is an option to roll 
this into the ATMS II implementation providing the selected vendor brings the capabilities and system 
features and functions necessary. However, CAD/AVL vendors may be unable to provide an integrated bus 
and rail alerts system. Currently, many CAD/AVL vendors provide only basic alerts functionality. 
Additionally, Metro may not wish to have its traveler information systems program constrained by the 
ATMS Il implementation (e.g., schedule, duration, features and functions trade-offs, etc.). 


Benchmarking 


A combined bus and rail alerts system is currently operational at MBTA (Boston), and CTA (Chicago); it is 
being planned at WMATA (Washington DC); and is being implemented as a pilot at Metro. 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 

S 636K S 1.0M 

Additional cost break down information may be found in the ROM Section 5. 
Assumptions 


e Costs assumed separate/new could-based service. 


Implementation Considerations 
Implementation Schedule and Key Dependencies 


This is one of the first projects recommended in the sequenced traveler information systems program. 
Once the enhanced multi-modal real-time aggregation system and single GTFS-realtime feed project 
described in the following project description is underway, it will begin to provide improved, consistent 
data to the alerts system, which will, in turn, provide accurate, real-time, multi-modal alerts to the 
recommended real-time passenger information (RTPI) portal on the Metro website, as well as the other 
Metro customer information systems. 
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Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year & 
2016 2017 2018 2019 2020 2021 2022 2023, 
(T7) 
(T6) 


(T.3) Multi-modal Alerts 
(T.6) Enhanced Multi-modal Real-time Aggregation System + Single GTFS-realtime Feed 
(T.7) Webpages with RTPI 


Enhanced Multi-modal Real-time Aggregation System + Single 
=i GTFS-realtime Feed 
Project: T.6 


Metro builds upon the existing agency open data and API systems (i.e., developer.metro.net) to aggregate 
information from ATMS II, SCADA, the alerts system, and, possibly, from NextBus (for bus predictions) to 
provide a single-source of traveler information including vehicle locations, arrival predictions, and alerts 
along with the implementation of a new, single, GTFS-realtime feed providing improved accuracy on 
customer-facing portals like the agency website and mobile app. 


Benefits 


e Improved traveler information system with alerts allows passengers to make more informed 
decisions and improves the customer transit experience. 


e Improved GTFS-realtime feed results in better accuracy of location information provided to 
passengers and improves the customer transit experience. 


e Provides a unique opportunity to use the aggregated data to feed downstream Metro 
systems such as traveler information webpages and apps. 


Technical Analysis Summary 


This provides a flexible solution to meet Metro’s customer needs for schedule, prediction, and service 
alerts info for rail and bus in a single, cohesive system. APIs and standardized feeds allow the 
dissemination of current, accurate schedule, prediction, and service alert information to third-party apps 
and websites through a single source, ensuring GTFS-realtime data is consistent with schedule data from 
bus and rail information systems. This allows developers to leverage existing apps or create new apps to 
meet Metro customer needs (e.g., ADA requirements). This will require access to API service be controlled 
and monitored. As well, changes to the GTFS-realtime feed, such as additional fields for data entry, may 
be more easily implemented. To achieve the benefits envisioned from this solution, the system must be 
integrated with both the bus and the rail schedule systems. Finally, consolidation of systems may reduce 
overall operations effort and IT support. However, this may be offset as an internal system requires 
additional effort for system operation, maintenance, and monitoring. 
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Benchmarking 


MBTA (Boston), BART (San Francisco Bay Area), TriMet (Portland) have had success developing 
aggregation systems. These systems form the foundation for their traveler information systems, and 
improve the agencies’ abilities to share consistent and accurate information. 


Many agencies that offer both rail and bus services have implemented or are planning to implement a 
single multi-modal GTFS-realtime feed including MBTA (Boston) and TriMet (Portland) 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 
$1.9M S$ 1.2M 


Additional cost break down information may be found in the ROM Section 5. 


Assumptions 


e The design, implementation, and testing of traveler information systems including, 
schedule, prediction, and alert information is directly available to the public and to third 
parties through APIs 


e The bus and rail systems have prediction functionality 


Implementation Considerations 
Implementation Schedule and Key Dependencies 


This solution depends on the Multi-modal Alerts System (T.3) to be implemented and the Rail Prediction 
Engine (T.5) to be underway first. As part of the overall recommended traveler information program, it is 
anticipated this project would utilize the improved rail prediction engine data from project T.S5 and would 
provide the harmonized data necessary to gain the best utility from project T.3. 


Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year & 


2016 2017 2018 2019 2020 2021 2022 2023 


( : | 


(T.3) Multi-modal Alerts 
(T.5) Rail-specific Prediction Engine 
(T.6) Enhanced Multi-modal Real-time Aggregation System + Single GTFS-realtime Feed 
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Customer-facing Systems 


‘ Massachusetts Bay 
Metro currently relies on NextBus modules that are iensposiation Aisthority 


embedded in the Metro website to relay schedule 
and arrival information to customers. However, 
customers are increasingly relying more on 
smartphones and mobile devices to access transit 


Realtime Subway | Realtime Gus | Realtime Rail |Green Line Live Map 


RED LINE Select a Station 


information. Web pages and apps that are able to —_ 
leverage those devices’ functionality, e.g., GPS Seca aon 


locations improve the customer experience. While Sub) Son 
Metro has made a considerable investment in 
customer information through NextBus, using the 
NextBus tools available can be confusing due to the 
large number of options available to users. By 
unifying the web pages available into an easier to 
navigate traveler information website and mobile 
app, Metro would significantly improve the Ioan 
customer experience. 


Application 
Rail and bus passenger information signs at stations “ 


and stops are also currently driven by a wide variety 
of systems with different capabilities and standards. 
The different systems require Metro staff to enter Pee 
information in multiple locations and maintain = 
knowledge of several operating systems. The 
numerous types of signs in use require maintenance 
staff to maintain replacement inventories for 


Standardized and Improved Data along with Standardized 
several different sign types and retain the Customer-facing Information Tools Improves Customer 


knowledge to repair them. These inefficiencies Experience System-wide 

result in extra costs and the possibility of incorrect 

information being presented to customers. Thus, Metro has expressed a need to unify the Transportation 
Passenger Information System under a common platform that reduces efforts to disseminate information 
via the signs and streamlines maintenance. 


The following recommended projects also are envisioned to build upon the improvements described in 
the sequenced projects above. 


Webpages with RTPI 


Project: T.7 


Metro redesigns the Metro bus and rail arrivals web pages to present real-time information including: 
schedule, predictions, vehicle locations and service alert information. Specifically, the redesigned pages 
will allow users to access real-time information for their specific route, direction, trip, stop, or any 
combination thereof. This option could be integrated with either the NextBus API or the Bus and Rail 
Traveler Information System (TIS) API. 


Benefits 


e Improved traveler information system with alerts allows passengers to make more informed 
decisions and improves the passengers’ transit experience. 
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Technical Analysis Summary 


This solution releases Metro from the limitations of the NextBus design and functionality, and provides the 
opportunity to implement a webpage that is responsive specifically to Metro and its customers’ need for 
real-time passenger information. These new and responsive webpages can be optimized for desktop and 
mobile device use, providing a consistent experience for customers across all platforms. 


This solution would either be limited to internal implementation resources or external developers. It is 
recommended that Metro contract with a vendor for the design and roll-out of the new webpage. The 
webpages could be provided as part of the ATMS II project implementation, as long as the ATMS II vendor 
possesses the technical capabilities to develop the webpages and their cost is not prohibitive. 


Benchmarking 


Many agencies have implemented or are planning to implement web pages with RTPI including TriMet 
(Portland), CTA (Chicago), MTC (New York City), and MBTA (Boston), RTD (Denver). 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 
S 381K S 433K 
Additional cost break down information may be found in the ROM Section 5. 


Assumptions 


e The Metro website has access to APIs with RTPI information 


e Hosting would be provided by existing hosting service 


Implementation Considerations 


Ideally, the web pages would be driven by an aggregation system as recommended in project T6 with the 
data provided via a single source alerts system as recommended in project T3. It should also be responsive 
to desktop computers (including laptops) or mobile devices (including tablets and smartphones), changing 
information displays and options based on characteristics of the device, e.g. screen size, GPS ability, and 
so forth. 


Implementation Schedule and Key Dependencies 


The Multi-modal Service Alerts system (T.3) needs to be implemented first to provide the alert 
information to be consumed by the webpages. 


Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year & 
2016 2017 2018 2019 2020 2021 2022 2023 
| = oo 
(T.6) 
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(T.3) Multi-modal Alerts 


(T.6) Enhanced Multi-modal Real-time Aggregation System + Single GTFS-realtime Feed 
(T.7) Webpages with RTPI 


September 2016 


NTCIP-compliant Station Signs with Common Sign Control 


Bi Project: 1.8 


Metro replaces existing non-compliant signs with National Transportation Communications for ITS 
Protocol (NTCIP)-compliant signs at bus stops, rail stations, and transit centers. Metro would also 
implement a common sign control system with an accessible AP! for controlling sign information. This 
reduces the number of systems required to maintain and operate, translating into direct operating cost 
reductions for Metro for the labor required to manage and maintain the signs and the spare parts 
necessary to have on hand. A common sign control system would also reduce the opportunity for 
incorrect or different information to be entered into any particular sign sub-system, ensuring more 
consistent information is disseminated across the customer information platform. 


Benefits 

e Reduced number of TPIS sign systems to maintain and operate. 

e Reduced labor required to manage and maintain signs. 

e Reduced incorrect or disparate information displayed at a given platform. 


Technical Analysis Summary 


A single sign control system for control of all Metro signs would reduce operations and maintenance 
requirements and free Metro from the limitations of NextBus support, features, and functionality. In 
addition, NTCIP-standardized interfaces allow for compatibility with other sign control systems. Utilization 
of APIs allows additional systems to have access to control the signs, e.g. an alerts system, allowing the 
NTCIP-compliant signs to be used by other passenger information systems. The public sign control system 
API could also be made available for developers to create apps to meet ADA requirements. 


Benchmarking 


NFTA (Buffalo) relies on NTCIP signs for the presentation of information at its stations. MBTA has 
integrated its signs with a traveler information aggregation system for consistent data. 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 
$ 6.8M $ 4.4M 


Additional cost break down information may be found in the ROM Section 5. 
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Assumptions 


e All signs are controllable through NTCIP standard 


Implementation Considerations 


It is anticipated the standardized signs would be integrated to pull data from the enhanced aggregation 
system implemented under project T.6 along with the Multi-modal Alerts System (T.3). 


Implementation Schedule and Key Dependencies 


Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year & 
2016 2017 2018 2019 2020 2021 2022 2023 
(T.6) 


(T.6) Enhanced Multi-modal Real-time Aggregation System + Single GTFS-realtime Feed 


(T.8) NTCIP-compliant Station Signs with Common Sign Control 


Rail Station Public Address System Upgrade and Integration 


Project: T.9 


Metro upgrades the public address (PA) systems to provide one consistent system across all rail stations, 
either through identification of a new system or utilizing an existing PA system and upgrading the PA 
systems at all stations to be compatible with the chosen system. The main considerations for Metro in 
meeting its PA needs are performance, reliability and cost. A single, unified system would increase the 
reliability of the PA system by removing redundant, and potentially error-prone procedures with the use 
of multiple systems. The increased capital costs to implement the new system would be offset by 
decreased operations and maintenance costs. A unified PA system also would improve the customers’ 
transit experience by providing consistent information throughout Metro’s transit system. 


Benefits 
e Improved reliability of the PA system 
) Improved customer transit experience by providing consistent traveler information 


throughout all modes and platforms 


Technical Analysis Summary 
This solution creates a single, unified PA system that eliminates duplicate systems and reduces efforts to 
maintain disparate systems. A unified PA would require integration with existing PA system equipment at 


the stations and platforms. The PA system could be integrated with the existing Traveler Information 
System (TIS) to satisfy ADA requirements. 
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Year 1 


2016 


Benchmarking 


While many agencies currently operate separate PA systems, many are considering consolidating them 
into single systems. MBTA (Boston) has had success in reducing operations efforts and costs by 
implementing a system-wide PA system for rail operations. 


Cost Summary 
CAPITAL COSTS O&M COSTS (10yr) 
§ 2.0M § 2.0M 


Additional cost break down information may be found in the ROM Section 5. 


Implementation Considerations 


There may be some cost reduction for the traveler information program if this project implemented at 
part of the ATMS II Rail project A.5i. 


Implementation Schedule and Key Dependencies 


Projects ATMS II Rail Implementation A.5i, and Enhanced Aggregation T.6 should be underway first, as the 


PA system would pull data from both newly implemented systems. 


Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year & 


2017 2018 2019 2020 2021 2027 


(A.5i) ATMS II for Rail 


(T.6) Enhanced Multi-modal Real-time Aggregation System + Single GTFS-realtime Feed 


(T.9) Rail Public Address System Upgrade 
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3.2 Video Streaming for Bus and Rail 


Rail and bus operations, as well as security groups, have expressed a need for the ability for live look-in for 


vehicles in emergency and other situations. Current international conditions and security threats will 
continue to push for the ability to view live on-board video. Bus controllers noted that a live look-in 


feature would allow for some process changes in responding to false emergency alarms on buses (i.e., a 


very high percentage of alarms were reported as false and are stretching law enforcement resources to 
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clear the alarms). Bus operations has also 
expressed a need to improve the safety of 
the bus operators, and rail operations 
staff have expressed a need for improved 
access to on-board video. 


For the Task 3 alternatives analysis, Task 4 
SWOT analysis, and Task 5 Cost Benefit 
Analysis, it was assumed that Metro has 
implemented a wireless data 
communication system for both bus and 
rail operations that has sufficient 
bandwidth to support streaming video. 
The differentiators between the 
alternatives were primarily the costs, 
future proofing, and which alternative 
would best meet Metro’s needs. The Example of Real-time On-board Vehicle Video Streaming for Bus 


highest scored alternative is E.V1 which 
reflects that providing real-time access to vehicle video when it is most needed at a much lower cost than 
the other alternatives is preferred. 


The following paragraphs provide details of the recommended video streaming project. 


j=\= Video Streaming for Bus and Rail 
” ™“ MProjects: V.3 + V.4 


This project involves enabling the streaming of the on-board video to the BOC and ROC during emergency 
situations. This project assumes each vehicle has an MGR with a cellular data connection that enables it to 
stream on-board video only during emergency situations. Metro has a pooled data plan for the entire fleet 
that is sufficient to enable a few vehicles to stream video during emergency situations. The video will be 
temporarily cached (but not stored) in the cloud, from where it can be streamed to viewers during an 
emergency. 


Benefits 


e The ability to view on-board video on demand during an emergency, which would improve 
the security of both the operator and passengers. 


° There would be reduction in the need for the involvement of the Sheriff when there is a 
false alarm. 


Technical Analysis Summary 


This project provides cost effective real-time access to on-board video when it is needed most—during 
emergencies. Video is retained on board so historical video will need to be manually retrieved from the 
on-board digital video recorder (DVR). In the event of a severe incident, the equipment may be damaged 
and lose all stored data. Streaming server's transition between on/off states may generate errors and 
comes with latency. Privacy issues may arise if there is a security breach of live video. 
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Benchmarking 


The Los Angeles Department of Transportation (LADOT) is upgrading its onboard hardware to enable real- 
time video streaming over a cellular network from vehicles on an as needed basis. 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 


S$ 6.1M S 3.0M 


Additional cost break down information may be found in the ROM Section 5. 
Assumptions 


e It is assumed Metro has implemented a cellular data network for data communications for 
the bus and rail fleets. 


e Video streaming increases the monthly cellular subscription (approximately $5 per vehicle) 
for a pooled cellular data plan 


e Video from vehicles in an emergency state is cached temporarily in the cloud but is stored 
on-board. 


Implementation Considerations 


Implementation of a high speed wireless data network should be implemented first or in conjunction. The 
ability to view streaming video from vehicles has only become feasible recently when 4G LTE cellular data 
service became readily available. Several agencies including LADOT are now planning to implement the 
viewing of real-time onboard video on an emergency basis now that the price for this service has dropped 
dramatically. Obtaining cellular data service to support continuous streaming of video from the vehicles 
may not be feasible today but could be in the future when 5G service becomes available. 


Implementation Schedule and Key Dependencies 


The figure below shows the time line for the implementation of the video streaming for bus and rail 
projects, and its dependency on the implementation of cellular data networks for the bus and rail fleets. 


Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 
2016 2017 2018 2019 2020 2021 2022 2023 
(0.5) (0.7) 
(V.3) (V.4) 
(0.5) Fleetwide MGR (and cellular data) for Bus (0.7) Fleetwide MGR (and cellular data) for Rail 
(V.3) Video Streaming for Bus (V.4) Video Streaming for Rail 
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a2 Yard Management Tools 


Metro bus and rail stakeholders indicated 
extensive needs to support vehicle 
management, status tracking, and 
maintenance support functions in the 
yards. Metro attempted to deploy a yard 
management module early in the 
operational life of the current ATMS, but 
the vehicle location accuracy was not 
sufficient. Rail stakeholders indicated the 
need for enhanced yard management tools 
that could address the specific 
configuration of each of the rail yards, as 
well as assist with tracking status and 
providing integration to M3 and related 
vehicle maintenance/yard spotter 
functionality. 


This is an example test display screen from the Metro-developed yard 
management tool pilot project (rail yard shown) 


Comprehensive yard management tools support the following general functions: 


e Automatic vehicle location tracking/placement, including 
identifying individual bus lanes /spaces and storage/primary 
track positions for rail vehicles 


e Support for vehicle assignments and dispatching for 
scheduled (e.g. from HASTUS) and unscheduled situations 
(e.g. regular service or service emergency response) given 
vehicle status and positions in the yard 


e Map views of the yard including placement of vehicles as 
available or unavailable for service in addition to status and 
location 

° Ties to vehicle maintenance systems to indicate status and 


condition (open work orders, critical items, etc.) 


° Operator vehicle location support (find my bus or rail vehicle 
based on operator ID or work assignment) 


° Yard spotter and vehicle inspection integration (optional) 


Metro has undertaken some in-house development efforts to 
provide a basic yard vehicle management and vehicle tracking tool. 
A pilot project was completed for the Blue Line rail yard but the tool 
will ultimately be expanded for use at the other rail and bus yards. Example of Modern Yard Management Tool User 
The in-house tool provides a substantial level of functionality and Interface 

information even in its pilot program form. 


This tool relies largely on manual input of vehicle location and status information into the system, similar 
to the magnetic or block displays often used for yard management, but it has the advantage of being 
available on-line to a wider variety of users at workstations. While mobile access to this tool has been 
considered, some stakeholder have voiced concerns about ensuring safety for personnel working in the 
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yard amongst the vehicle storage and movement areas. The development platform of the tool means that 
future data integration efforts could be supported and/or yard management functionality enhanced over 
time. Initial responses to the demonstration use of the tool by Metro have been positive and have led to 
development efforts to cover remaining rail and bus yards. 


Prepare for and Implement Independent Bus + Rail Yard 
Of Management System 
Projects: Y.4+Y.5 


This effort builds on current Metro efforts to support basic vehicle/yard tracking and status for bus and 
rail, but would not necessarily provide automatic assignments of vehicles to service blocks. Integration to 
the TDB and M3 would be included over time. This alternative can be viewed as combining the highest 
priority functions of D.M1 or D.M2 with the in-house development efforts of Metro. This alternative would 
take longer to implement as it would be phased over time. 


Benefits 


e Yard management tools would reduce the amount of manual labor performed by 
maintenance and operations staff. 


Technical Analysis Summary 


The in-house tool developed by Metro appears highly functional and successful. CAD/AVL system provided 
yard management tools have proven to be relatively high risk and are sometimes unable to meet the 
agency specific needs and the idiosyncrasies of yard configurations and vehicle placement. While a 
contracted fully custom or separate efforts offers promise, the costs would be substantially higher. 


Improvements to on-board architectures and yard and mobile data communications are expected to 
radically transform the data communications and vehicle information available at the yards. As newer 
vehicles come on-line and offer enhanced vehicle health and status information automatically, this will 
dramatically impact and hopefully improve what can be achieved with yard management tools. In short, 
this is an area where the recommendation is for Metro to continue in-house development efforts, 
consider easy integration and functionality enhancements and bide its time until rail and bus fleet turn 
over makes a more comprehensive yard management tool easier, more functional, and less costly to 
implement. However, many of the manual functions currently performed to collect rail vehicle data could 
be simplified, semi-automated, and integrated with the in-house tools to continue to address priority 
needs in this area. 


Benchmarking 


SAP (http://go.sap.com/solution.html) custom solutions have been deployed for Canadian Railways; 
Trapeze Enterprise solutions for the Chicago Transit Authority (CTA). 


Cost Summary 


CAPITAL COSTS O&M COSTS (10yr) 


$11.6M $5.7M 


Additional cost break down information may be found in the ROM Section 5. 
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Assumptions 


° New on-board architecture and connected vehicles in place for bus and rail. 
e Yard Wi-Fi coverage in place for bus and rail. 
e Continued development of Metro in-house yard tracking applications. 


Implementation Considerations 


The In-house yard tracking system should allow for near-term and future integration with M3 (or 
replacement) as well as enhanced yard management systems for bus and rail. 


Implementation Schedule and Key Dependencies 


The figure below shows the time line for the preparation and implementation of the Yard Management 
System. There are no critical dependencies to other projects. 


Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year & 


2016 2017 2018 2019 2020 2021 2022 2023 


(Y.4) Prepare for Independent Bus + Rail Yard Management System 


(Y.5) Implement Independent Bus + Rail Yard Management System 


3.4 SCADA 


SCADA provides monitoring and control functions for the controllers at the ROC. The SCADA human- 
machine interface (HMI) computers at the ROC provide the monitoring, alarm and control functions 
through a graphic interface. A cable transmission system (CTS) provides the communication link from the 
SCADA HMI to the SCADA remote terminal units (RTUs), which directly interface to the equipment in the 
field. Different SCADA HMI vendor platforms are currently in operation at the ROC, but Metro is currently 
in the process of moving all rail lines to the ARINC Advanced Information Management (AIM®) system. 


The Task 1 Needs Assessment identified a significant need to make SCADA data available to other users 
besides the ROC controllers, especially maintenance and security staff. Controllers at the ROC who use the 
SCADA HM are primarily responsible for train movements, but the nature of the SCADA architecture also 
requires them to supervise and manage wayside systems unrelated to train movements. The additional 
responsibility of the wayside systems is a distraction from the higher priority of ensuring safe train 
movements. Maintenance and security staff who are primarily responsible for the wayside systems have 
limited direct access to SCADA information. 


Generally, SCADA provides monitoring, alarms, and control of equipment for the following systems: 
traction power, train control, electrical, mechanical, tunnel ventilation, communications systems, fire 
detection, security, and other miscellaneous systems. SCADA generates important alerts and information 
for rail operations and maintenance. This data is not always easily accessed outside of the SCADA systems. 
In addition, the alerts are not always directed specifically to the parties that need them, and are broadcast 
to a wide set of users. 
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Two projects were identified to address the identified needs for SCADA. 


SCADA HMI for Maintenance Staff 


Project: S.4 


This project adds a SCADA interface for use by staff other than the ROC operators such as maintenance 
and security. This new SCADA interface would be constructed as an extension of the existing ARINC system 
with new workstations and new graphics. The new graphic displays would be optimized for maintenance 
functions and would limit control capability to prevent accidental interference with ROC controllers. The 
new graphics would include alarms for maintenance and security. The existing SCADA HMI for the ROC 
controllers would then be reduced or its functions simplified due to the functions that have been assumed 
by the Maintenance SCADA. Essentially, this project is a division of SCADA functions into a Maintenance 
SCADA and Rail Operations SCADA. 


Benefits 


e The primary benefit is freeing the ROC controller from being an information conduit for 
maintenance and security staff. This will improve the efficiency and effectiveness for ROC 
controllers who can focus on train movements. 


e Maintenance staff will benefit with an interface that is tuned to their needs. There will be 
improved efficiency and * 
effectiveness of the maintenance >\ "be" 
staff due to their improved access to ca 
system status and alarms. Hesiod bas ( ms » 
e Security CCTV staff will benefit with Tt 
improved alarm displays for security yea ia 
related points in the SCADA system. 


Technical Analysis Summary | Maintenance + Alarms > SCADA 
\ HM L \ 


This project addresses the identified need Tie Alarms 
for improved management of alarms and 


better relevance of the alarm information 


IA\ 
LY as W\\ 
ale Status : 
~~ Maintenance ee 
r \ Control Z \ 
/ Historical Data 0 = / ' 
{ (New) \ I : (existing) \ 
/ 


Security 


Alarms 


presented directly person who can respond. Status 
Control aa _ _ - 
This project also addresses another SO a Ce 
— <— veticle x —! 


identified need: the ability to send rail 2 SES OA 
Operator 

system intrusion alarms directly to security + ° 
Staff. (equip 8 

ery 
Cost Summary 
CAPITAL COSTS O&M COSTS (10yr) 
S 683K S 105K 


Additional cost break down information may be found in the ROM Section 5. 
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Assumptions 


e The ARINC SCADA software will be re-used. 
e Metro’s licensing agreement with ARINC includes unlimited SCADA clients. 


e Development costs of new graphics will depend on the utility of the existing graphics for 
maintenance needs and security purposes. 


e Most of the ROM costs are for graphics development. 


e New client workstations and expansion of the SCADA network to maintenance staff 
locations are needed. 


Implementation Considerations 


Metro is in the process of moving all rail SCADA system to the ARINC platform. While it would be possible 
to begin the conceptual pre-design stages of this project at any time, it will be probably be more efficient 
to commence the actual development after the SCADA migration of all rail alignments is completed. 


Implementation Schedule and Key Dependencies 
The figure below shows the time line for the development of the SCADA HMI for Maintenance interface. 


Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 


2016 2017 2018 2019 2020 2021 2022 2073 


(S.4) SCADA HMI for Maintenance Staff 


SCADA Message Gateway 


Project: S.5 


This project implements a message gateway with an interface to SCADA to automatically send email, text 
or phone messages as triggered by alarms or events in SCADA. The person who receives the alarm 
responds with an alarm acknowledgement. The acknowledgement is received and logged by the SCADA 
system. 


An example use case for an alarm sent and acknowledged via text message is as follows: 


An equipment problem is detected by SCADA PLC. 

The SCADA PLC sends an alarm to the SCADA HMI (the ARINC system). 

The SCADA HMI sends an alarm to Message Gateway. 

The Message Gateway sends an SMS text to the responder (Metro maintenance staff or contractor). 
The responder acknowledges the alarm via text message. 


Message Gateway sends the alarm acknowledgement to SCADA HMI. 


Oy Oe NS oe 


The SCADA system logs the alarm activity including the acknowledgement. 
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Implementation of this gateway can be accomplished with off-the-shelf alarm notification products that 
can be integrated with the SCADA HMI (ARINC). Alternatively, the ARINC SCADA platform has been 
developed with at least a beta version of this capability. 


Benefits 


e A significant advantage is the reduction of work load for the ROC controllers who maintain 
awareness of equipment readiness but no longer need to contact maintenance responders. 


e The acknowledgment aspect of this upgrade provides a simple level of response 
coordination. If a potential responder receives the alarm but is unable to respond, they can 
decline to respond. The system will then message the next person on the responder list. 


° This upgrade is compatible with a business model where Metro contracts with outside 
vendors for certain maintenance areas. A system or equipment under warranty can have 
alarms configured to activate an outside maintenance vendor directly. 


e SCADA logging of the alarm-related ae 
activity provides a basis for evaluation Gia 
of a maintenance vendor’s < at 
responsiveness. Acknowledge 

Technical Analysis Summary a _ 

" Va a 
. . . oe | \\ ; Email or é ae: on 

This project addresses the identified need for /y\ (Text Message _) Gateway / \ HMI / 

. bed //\\ si Pe \ ie 

improved ability of the SCADA system to Maintenance WA an ; 

automatically generate data and forward it OF : 
Vendor Automated Voice Message 

to the relevant personnel. An automated 

messaging function frees the ROC controllers ae. 

from performing this routine task. This will ae 

/ 
allow the controllers to focus on higher ‘ - 
priority activities such as managing train 

movements. 

Cost Summary Aion’ 

a) 

CAPITAL COSTS O&M COSTS (10yr) 

S 397K S 12K 

Additional cost break down information may be found in the ROM Section 5. 

Assumptions 

° Off-the-shelf hardware and shrink-wrapped software costs are small compared to the labor 
necessary for integrating with SCADA and for configuring the alarm notifications. 

e Costs include the design phase and project management costs during construction. 

Implementation Considerations 

Implementation of the gateway will require the direct involvement of Metro maintenance staff to 

appropriately configure the notifications. There are a number of different ways to send messages 

including phone call, SMS text and email. Texting is probably the most preferable for most people. 
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However, this could mean that Metro is obliged to provide smartphones or reimburse employees for use 


of their personal smartphones. 


Implementation Schedule and Key Dependencies 


Year 1 Year 2 Year 3 Year 4 Year 5 


2016 2017 2018 2019 2020 


(S.5) SCADA Message Gateway 
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Year 6 


2021 


Year 7 


2022 


Year 8 


2023 
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4 Strategic Plan Timeline and Relationships between 
Fleet Systems 


This section provides an overall Strategic Plan 


Al Overview timeline highlighting key dependencies 
between current, planned, and 

This Strategic Plan describes a series of on-going, recommended projects, along with diagrams 

recommended, and supporting fleet communications illustrating impacts to current and planned 

and technologies projects that seek to fulfill the needs system interfaces as a result of the 

outlined by Metro at the outset of the planning effort. recommended projects. 


Any Plan is subject to funding and policy realities and 

priorities that impact details of the projects 

implemented, timing, and the relative sequencing of projects. This section of the Plan provides a big 
picture overview of the recommended, existing and planned projects outlined in a timeline format. 


This Plan is intended to be “living document” where timelines and cost estimates can be updated over 
time to reflect Metro’s changing priorities and on-going development efforts. The timeline in this section 
collectively lists projects with anticipated timeframes out to 2025. Planned projects beyond that 
timeframe tend to fall into on-going project monitoring, maintenance, and configuration management. 
The ROM cost estimates provided in the following section reflect current 2016 estimates using current US 
dollars. This Plan provides sufficient detail to allow the projects to be implemented separately or 
aggregated as Metro’s needs may dictate. 


4.2 Relationships between Fleet Systems Projects and Timing 


Figure 3 displays the overall Strategic plan and timeline for the recommended projects and supporting 
projects. Key dependencies are noted as arrows between projects, and each project is identified with a 
title and ID code that references back to the individual project descriptions. The timeline lists three basic 
categories of projects: 


e Foundational — Foundation project recommendations are core elements and efforts that are required 
to make effective progress and enable the use of all the remaining project functionality described in 
the Build-On and Independent categories. This category contains the basic voice and data 
communications project required to support fleet systems upgrades and replacements. It also 
contains the ATMS II project that replaces the aging current ATMS and significantly enhances it to 
include new functionality, improved operational interoperability, and rail support functions. Finally, 
this category includes incorporation of a new on-board systems architecture that started with 
Metro’s existing Connected Fleet Vehicles & Facilities project and is incorporated into all the other 
remaining project recommendations. Without the foundational projects in place, Metro will find it 
much more difficult to implement and make full use of the broader set of fleet systems and 
supporting traveler information functions described in this Plan. 


e Supporting — Supporting category projects seek to leverage the foundational efforts, particularly the 
communications and elements of ATMS II to provide more robust and capable fleet management 
solutions. Metro is already undertaking some efforts in this area with the DIMs project for video 
requests/management as one example. The full implementation and success of these efforts will 
ultimately hinge on the foundational elements. Some of these traveler information projects and 
related SCADA upgrades can be undertaken without direct integration with the foundational project, 
but the success of most of the efforts will be leveraged upon elements of ATMS II, communications 
improvements, and the implementation of a more open and flexible on-board architecture. 
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e = Visionary — Visionary projects Include both Connected Vehicle (CV) and autonomous vehicle concepts. 
The identified items are not intended to represent recommended projects with associated costs. 
Instead they are estimated timeline triggers for Metro’s consideration in moving forward with 
autonomous and connected vehicle applications for transit. As discussed in the specific Connected 
and Autonomous vehicle section of this Plan, communications and fleet systems have a pivotal role to 
play in the on-going roll out and operationalization of CV functions and projects. These elements are 
listed for reference purposes for Metro’s on-going planning and preparation for CV and autonomous 
vehicle efforts. 


For each project listed in the timeline: 


e Recommended projects described in detail in the plan are highlighted, 
e Color dots represent bus (green), rail (orange), or both. 
e Abbreviated names are noted in the reference legend under the timeline. 


In addition, other key anticipated timeframes are noted such as the anticipated completion of Mobile 
Gateway Router (MGR) fleet-wide deployment and the anticipated ESOC operations center readiness for 
fleet systems transition/integration. A separate effort by Metro is noted for the upgrade and replacement 
of M3, the maintenance management application platform that receives and provides data to a number of 
other fleet systems. 


Figure 4 provides another view of the relationship between the recommended projects and all known 
planned and current ongoing projects at the time of this Plan. A brief description for each of these 
projects may be found in Appendix B. 
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Figure 3: Strategic Plan Technology Program Project Timelines and Dependencies 
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@ 0.5  Fleetwide MGR (and cellular data) for Bus @5.3 SCADA Security Enhancements 
@ 0.6 APCs Replacement/Upgrade YARD TOOLS & COMMUNICATION @S.4 SCADA HMI for Maintenance Staff 
@ 0.7 — Fleetwide MGR (and cellular data) for Rail @@ \.1 —_ Metro-developed Yard tool (bus underway, rail complete) @S.5 SCADA Message Gateway 
@@ 0.8 Emerging Bus + Rail Architecture Implementation @ ¥.2 Upgrade WLAN in Bus Yards @S.6 — Standardization of ARINC SCADA (Green Line) 
@@ 0.9 Prepare for Onboard Systems Configuration Management @ Y.3 Implement WLAN in Rail Yards 
@@ 0.10 On-board Systems Configuration Management @@ 4 __ Prepare for Independent Bus + Rail Yard Management System MAINTENANCE 
@@ 0.11 Review and Refresh Bus + Rail On-board Architecture @@Y.5 _ Implement Independent Bus + Rail Yard Management System Pi M3 Replacement 


@@Y.6 — Metro-developed Yard Tool Refresh 
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Figure 4 Overview of Current/Planned and Recommended Projects 
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4.3 Relationships between Fleet Systems 


The many fleet systems operated by Metro have a number of interfaces and levels of integration both 
between each other and to other Metro non-fleet systems. As part of the Strategic Plan, an effort was 
made to document and summarize some of these interfaces and relationships. More detailed 
documentation of Metro’s existing systems is available in Technical Memo for Task #1 — Needs 
Assessment. As a high level summary, Figure 5 displays the system to system relationships between 
Metro fleet and supporting systems. Figure 6 shows a more detailed view of the Transit Database (TDB), 
which plays a key role in aggregating and fusing key data elements from fleet and supporting systems 


External 
Systems 
Data Analysis ft 
& Reporting Other Agency 
Staff 


Central 
Enterprise 
Systems 


BOC Controller 


\ 
vy 
=me 
2 
i 
=e <- 
je =< 


al Passenger 


Information 


| 
M 
= 
. 
\ 
\ 
Ni 
: 
x 
=ie < - 


Security 
Rail CCTV Staff 


Legend 
Operations 


emetm f 
a ners 


——* Automated Data Push/Fetch 


2 ———* Manual Data Entry/View 
Maintenance 


Figure 5 LA Metro Existing Fleet Systems Relationships and Interfaces 
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Figure 6 Illustration of TDB Interfaces 


As recommended projects were developed for this Plan, the existing system to system relationships and 
interfaces were reviewed to determine where potential impacts might occur that would require: 


e Integration of new fleet systems elements, 
e Major upgrades or updates to existing fleet systems, and/or 
e Minor upgrades or updates to existing fleet systems. 


Figure 7, below, provides an updated version of Figure 5. Figure 7 highlights new and upgraded fleet 
system elements. In addition, red arrows or connections indicate new and updated interfaces that will 
likely need to be implemented by Metro during the design of the new fleet systems. Figure 7 is not 
intended to specify an architecture, but instead to give a high level overview of areas of potential impact 
when the recommended projects are implemented. 
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Commensurately, as the recommended projects are implemented, the TDB will require modification and 
updating. Metro’s Business Intelligence (BI) and reporting tools will also require modifications. In 


particular, the new ATMS II will provide some substantially enhanced functionality that will require new 
interfaces with the TDB and Metro’s reporting tools. 
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5 Rough Order of Magnitude Program Costs 


“ = 
The following are rough order of magnitude (ROM) costs ( This section provides detailed ROM costs for 
that have been developed for the recommended projects. each recommended project, including ten 
Some of the cost estimates are based on costs provided by years of Operations and Maintenance costs. 
vendors and some of the cost estimates are based on 

projected support required to procure, implement, and Xe Z 


maintain the systems. 


al Recommended Project Costs 


5.1.1 ATMS II for Bus and Rail (A.1 thru A.S) and Emerging Trends On-board Architecture (0.2 
thru 0.10) 


The following ROM costs for ATMS II were developed from inputs from CAD/AVL vendors and 
independent costs estimates. The ROM costs are based on the following assumptions: 


° The recommended VoIP for bus voice communications and cellular network for bus and rail 
data communications costs are separate but the systems will be implemented either in 
advance of ATMS || Bus and Rail or in conjunction. 


e The costs do not include further development required by Cubic to provide real-time TAP 
updates to the fareboxes. 


° The recommended Rail Arrival Prediction Engine is implemented either in advance of ATMS 
I Rail or in conjunction. 


° The recommended Multi-modal Service Alert System is implemented either in advance of 
ATMS II Bus and Rail or in conjunction. 


° Bus fleet is 2,450 vehicles 

e Rail fleet is 566 vehicles 

e Project oversight costs are split between the Bus and Rail implementations 
e Two full days of training for each CAD user. 

° Two full days of training for each maintenance personnel. 

° Two union FTEs for Metro oversight of installations. 


Cost savings could be realized if the installation of the onboard ATMS equipment is performed by 
Metro staff, rather than the ATMS II contractor staff. The costs are exclusive of taxes, freight, and 
any applicable duties. 
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Table 1: ATMS II for Bus Order of Magnitude Costs 


Vendor Costs 


Hardware, On Bus Quantity | Unit 
MDT, dual purpose control head with farebox 2450 EA 3,550,098 
On Board Processor 2450 EA 4,568,049 
Mobile Gateway Router 2450 EA 5,572,909 
Cellular Modem 2450 EA 2,143,750 
VoIP 2450 EA 1,617,000 
ATMS voice radio backup interface 2450 EA 355,010 
ATMS data radio backup interface 2450 EA 502,170 
WLAN Radio 2450 EA 416,500 
GPS Receiver 2450 EA 122,500 
Other AVL Hardware 2450 EA 4,079,250 
State of the art APC Sensors 2450 EA 6,322,593 
Internal LCD Signs for AVA and Passenger 

Information 2450 EA 4,992,075 
Farebox Interface for single sign on, AVL data, 

farebox alarms 2450 EA 294,000 
Headsign Interface 2450 EA 318,500 
Silent Alarm Switch Interface 2450 EA 183,750 
PA System Interface 2450 EA 710,500 
Bus Signal Prioritization Interface 2450 EA 122,500 
On Board Video System Interface for Real-Time 

Video Streaming 2450 EA 220,500 
On Board Vehicle Health Monitoring 2450 EA 710,500 
Vehicle Installation 2450 EA 5,814,667 
Hardware, Road Supervisor Vehicles Quantity Unit 
Cellular Modem 65 EA S 911 S 59,200 
On Board Processor 65 EA S 3,631 S 236,000 
Mobile Data Computer (MDC) or Tablet 65 EA $ 2,773 Si 180,267 
GPS Receiver 65 EA S 62 S 4,000 
Power Supply 65 EA S 105 S 6,800 
Mounting Hardware 65 EA S 560 S 36,400 
Hardware, Backend & Infrastructure Quantity Unit 
CAD Workstations, BOC 24 EA 3,397 81,520 
CAD Workstations, Emergency Dispatch Center 12 EA 3,397 40,760 
Fixed End Servers 1 LOT 887,853 887,853 
CAD Workstations, Divisions 11 EA 4,105 45,155 
Yard Workstation 11 EA 3,843 42,268 
Maintenance Workstations 11 EA 3,895 42,845 
Contracted Services Workstations 3 EA 4,195 12,585 
WLAN Interface to Arruba WiFi network in Yards 11 EA 7,865 86,515 
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Hardware, Spares Quantity Unit Unit Cost Extended Cost 


10% Fixed Route Spares 245 EA 2,005,125 
10% Road Supervisor Spares 7 EA 17,710 
10% Infrastructure Spares 1 LOT 60,540 
Software Quantity Unit 

CAD Software including VoIP, BSP functionality, 

Hastus interface, bus bridge, real-time predictions 1 LOT S 2,426,490 2,426,490 
Interface to Cellular Data network, radio network 1 LOT S 181,040 181,040 
Video streaming during an SAS (if not included in 

standard product) 1 LOT S 75,600 75,600 
Project Management Quantity Unit 

Project Management Staff 1 LOT S 4,337,935 4,337,935 
Project Management Meetings 1 LOT S 450,000 450,000 
Design Reviews 1 LOT S 509,350 509,350 
Training 1 LOT S 274,745 274,745 
Acceptance Tests 1 LOT S 529,470 529,470 
Documentation 1 LOT S 323,000 323,000 
Performance Bond 1 LOT S 3,171,894 3,171,894 
QA Person over life of installs 1 LOT S 400,000 400,000 


Consultant Costs Quantity Unit Unit Cost Extended Cost 


Engineering 1 LOT S 150,000 

Implementation Support 1 LOT S 1,800,000 
Agency Costs Quantity Unit 

Project Oversight PM 5 EA 150,000 450,000 

Project Oversight Assistants 2 EA 100,000 600,000 

CAD User Training 70 LOT 1,156 93,097 

Vehicle Maintenance Training Development 22 LOT 723 18,287 

Integration and interfaces 5 EA 20,000 100,000 

Subtotal Vendor Costs 59,141,887 

Contingency 5,914,189 

Subtotal Consultant Costs 1,950,000 

Subtotal Agency Costs 1,261,383 


Total $ 68,267,000 
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Support Costs Quantity Unit Unit Cost Extended Cost 


Vendor Annual Cost for Post Warranty Hardware 
and software support 10 EA S 1,300,000 13,000,000 
Agency Maintenance Costs 10 EA S 1,032,000 10,320,000 


Hardware Refresh Costs Quantity Unit Unit Cost Extended Cost 
Server replacements after 5 years 1 LOT $6,000,000 $6,000,000 


Total $ 29,320,000 


Table 2: Emerging Trends On-board Architecture for Bus Order of Magnitude Costs 


Vendor Costs Quantity Unit Unit Cost Extended Cost 
Separate IVU Comparison Testing Equipment 2 EA 
Field install 1 EA 
Bench Test Setup & Equipment 1 EA 
Testing Software 1 LS 100,000 100,000 
Acceptance Tests 1 LS 200,000 200,000 
Documentation 1 LS 100,000 100,000 
Consultant Costs Quantity Unit Unit Cost Extended Cost 
Engineering 1 LS 250,000 250,000 
Implementation Support 1 LS 500,000 500,000 
Agency Costs Quantity Unit Unit Cost Extended Cost 
Project Oversight 2 LS 150,000 300,000 
Agency CM Efforts & On-Board Architecture 5 EA 75,000 375,000 
Testing 5 EA 86,500 432,500 
Capital 
Subtotal Vendor Costs 457,500 
Contingency 10% 120,750 
Subtotal ee 750,000 
Subtotal Agency Costs 1,107,500 
Total 2,436,000 
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Support Costs Annual Cost 
Vendor Annual Cost for Post Warranty 1 Ls 10% | § 45,750 
Hardware and software support 

Agency Staff - On-Going Architecture 05 Ls é 150,000 é 75,000 
Maintenance 


10 Year O+M 
Total $ 1,208,000 


Table 3: ATMS II for Rail Order of Magnitude Costs 


Vendor Costs 


Hardware, On Rail Vehicle Quantity Unit 
MDT 566 EA 1,416,600 
On Board Processor 566 EA 1,072,920 
Router 566 EA 1,358,415 
Cellular Modem 566 EA 506,570 
WLAN Radio 566 EA 939,560 
GPS Receiver 566 EA 28,300 
Other AVL Hardware 566 EA 2,000,880 
APC Sensors 566 EA 3,282,380 
Internal LCD Signs for AVA and Passenger 

Information 566 EA 1,217,540 
Headsign Interface 566 EA 73,580 
Silent Alarm Switch Interface 566 EA 42,450 
PA System Interface 566 EA 234,890 
On Board Video System Interface for Real-Time 

Video Streaming 566 EA 50,940 
On Board Vehicle Health Monitoring 566 EA 181,120 
Vehicle Installation 566 EA 2,144,260 
Hardware, Field Supervisor Vehicles Quantity Unit 

Cellular Modem 32 EA 91,840 
On Board Processor 32 EA 94,400 
Removable Mobile Data Computer (MDC) or 

Tablet 32 EA 72,107 
GPS Receiver 32 EA 1,600 
Power Supply 32 EA 2,720 
Mounting Hardware 32 EA 14,560 


September 2016 85 


BUS AND RAIL FLEET SYSTEMS STRATEGIC PLAN 


Prepared for Los Angeles Metropolitan Transportation Authority by EIGER TechSystems 


Hardware, Infrastructure Quantity Unit 
CAD Workstations, ROC 9 EA S$ 5,377 48,390 
CAD Workstations, Rail Divisions 9 EA $ 4,457 40,110 
Yard Workstation 9 EA S 4,457 40,110 
Maintenance Workstations 9 EA S 4,543 40,890 
WLAN Interface to Arruba Wifi Network at Yards , EA $ 13,660 122,940 
Fixed End Servers 1 LOT S 1,053,970 1,053,970 
Hardware, Spares Quantity Unit 
10% Rail Vehicle Spares 57 EA S 8,370 | S 477,087 
10% Field Supervisor Spares 4 EA 5 3353.5 13,413 
Software Quantity Unit 
CAD Software including TSP, Interface to Hastus, 
bus bridge, real-time predictions 1 LOT 389,120 389,120 
Interface to Cellular Data network 1 LOT 127,690 127,690 
Video streaming during an SAS (if not included in 
standard product) 1 LOT 25,200 25,200 
Project Management Quantity Unit 
Project Management Staff 1 LOT S$ 1,821,973 1,821,973 
Project Management Meetings 1 LOT 5 125,000 125,000 
Design Reviews 1 LOT S 254,675 254,675 
Training 1 LOT S$ 116,070 116,070 
Acceptance Tests 1 LOT S 259,823 259,823 
Documentation 1 LOT S 129,447 129,447 
Performance Bond 1 LOT S 356,390 356,390 
Consultant Costs Unit Cost Extended Cost 
Engineering 1 LOT S 250,000 
Implementation Support 1 LOT S 600,000 
Agency Costs 
Project Oversight 4 EA S 150,000 | $ 900,000 
CAD User Training 54 LOT S 1,156 S 71,817 
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Subtotal Consultant 
Costs 


Contingency 


Subtotal Agency Costs 


20,269,929 


850,000 


2,026,993 


971,817 
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Total 
A Ein 2 = | 


O&M 


Support Costs 


Vendor Annual Cost for Post Warranty Hardware 


and software support 10 EA 420,000 4,200,000 
Agency Maintenance Costs 10 860,000 8,600,000 


Hardware Refresh Costs 


Server replacements after 5 years $2,000,000 | $ 2,000,000 


Total S 14,800,000 


Table 4: Emerging Trends On-board Architecture for Rail Order of Magnitude Costs 
Vendor Costs Quantity Unit Unit Cost Extended Cost 
Separate IVU Comparison Testing 1 EA 10,000 
Equipment 
Field install 1 EA 2,500 
Bench Test Setup & Equipment 1 EA 35,000 
Testing Software 1 LS 50,000 
Acceptance Tests 1 LS 100,000 100,000 
Documentation 1 LS 50,000 
Consultant Costs Quantity Unit Unit Cost Extended Cost 
Engineering 1 LS S 150,000 | $ 150,000 
Implementation Support 1 LS S 175,000 | $ 175,000 
Agency Costs Quantity Unit Unit Cost Extended Cost 
Project Oversight 0.5 LS 150,000 75,000 
Agency CM Efforts & On-Board 3 EA 75,000 225,000 
Architecture 
Testing 3 EA 86,500 259,500 
Capital 
Subtotal Vendor Costs S 247,500 


Contingency 10% | S$ 57,250 
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Subtotal Consultant 


Costs $ 325,000 
Subtotal Agency Costs $ 559,500 
Total $ 1,189,000 


Support Costs 


Vendor Annual Cost for Post Warranty 
Hardware and software support 
Agency Staff - On-Going Architecture 
Maintenance 


1 LS 5% 12,250 


0.5 LS $ 150,000 75,000 


Total 
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5.1.2 


VoIP System for Bus (C.3) 


The following ROM costs for implementation of a Voice over Internet Protocol System are based on the 


following assumptions: 


° Metro will continue to use its existing voice radio as a backup to the VoIP system for five 
years. 

e 2450 bus fleet size, 200 portables for road supervisors and maintenance staff 

e The cost is exclusive of taxes, freight, and any applicable duties. 


Table 5: VoIP for Bus with Radio Backup Order of Magnitude Costs 


Cellular Vendor Quantity | __Unit 
Fixed Route Vehicles - Cellular Card 2450 EA 150 367,500 
Non-Revenue Vehicles - Cellular Card 65 EA 150 9,750 
Portables and Accessories 200 EA 2,800 560,000 
Central Site Equipment 1 EA 250,000 250,000 
Spares 1 LOT 10% 93,725 
Project Management, Eng., Overhead 1 LOT 30% 356,175 
Training 10 | PERSONS 2,500 25,000 
Integration with CAD (Central Equipment) 1 LOT 1,000,000 1,000,000 
Integration with CAD (On-Board Equipment) 1 LOT 500,000 500,000 
Warranty (5 Years + 5 Years Post-Warranty Call Support) 1 LOT 15% 178,088 
Contingency 1 LOT 20% 668,000 
Performance Bond 1 LOT 2% 67,000 
Consultant Costs Quantity Unit Unit Cost Extended Cost 
Engineering 1 LOT 407,500 
Implementation Support 1 LOT 407,500 
Contingency 1 LOT 82,000 
Agency Costs 

Project Oversight 1 FTE $ 100,000 100,000 


Subtotal Cellular Vendor 
Subtotal Consultant 
Subtotal Agency Costs 


Total 


4,075,000 


897,000 


100,000 


$ 5,072,000 


O&M 
Support Costs 

Quantity Unit Monthly Cost Extended Cost 
Leased Data Communications (fixed-route + non-revenue 
+ portables) 2715 EA 5,538,600 
Radio System Maintenance 1 FTE 840,000 
Radio Site Leases (for five years) 6 EA 3,600,000 
Agency Oversight (.1 FTE for 10 years) 0.1 FTE 100,000 
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Total | $ 10,079,000 | 
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5.1.3 


Data Communications System for Bus and Rail (C.2 + C.5) 


The following ROM costs for implementation of a new data communication system are based on 


the following assumptions: 


e Mobile gateway routers have been installed on the entire fleet. 


e = The cost is exclusive of taxes, freight, and any applicable duties. 


e Leased data communications cost for bus includes service for 2450 buses, 65 non-revenue 


vehicles, 200 portables 


e Leased data communications cost for rail includes service for 566 vehicles and 32 non- 


revenue vehicles 


Table 6: Commercial Cellular Data System for Bus Order of Magnitude Costs 


Cellular Vendor Quantity Unit 
Fixed Route Vehicles - Cellular Card (provide, install, 

commission) 2450 EA 150 367,500 
Non-Revenue Vehicles - Cellular Card (provide, install, 

commission) 65 EA 150 9,750 
Central Site Equipment 1 EA 100,000 100,000 
Spares (10%) 1 LOT 10% 47,725 
Project Management Engineering, Overhead 1 LOT 30% 143,175 
Training 10 | PERSONS 2,500 25,000 
Integration with CAD (Central Equipment) 1 LOT 500,000 500,000 
Integration with CAD (On-Board Equipment) 2515 LOT 200 503,000 
Warranty (5 Years + 5 Years Post-Warranty Call Support) 1 LOT 15% 71,588 
Contingency 1 LOT 10% 177,000 
Performance Bond 1 LOT 2% 35,000 
Consultant Costs Quantity Unit Unit Cost Extended Cost 
Engineering 1 LOT 198,000 
Implementation Support 1 LOT 198,000 
Contingency 1 LOT 40,000 
Agency Costs 

Project Oversight 1 FTE $ 100,000 $ 100,000 


Subtotal Cellular Vendor 
Subtotal Consultant 
Subtotal Agency Costs 


Total 


1,980,000 


436,000 


100,000 


O&M 
Support Costs 
Quantity Unit 
Leased Data Communications (Fixed + non-revenue + 
portables) 2715 EA $ 15 $ 4,887,000 
Leased Backhaul Circuits 4 EA $ 300 $ 144,000 
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System Maintenance 1 LOT $ 2,000 | $ 240,000 
Agency Oversight (.1 FTE for10 years) 0.1 FTE $ 10,000 $ 100,000 


10 Year O+M 


Total $ 5,371,000 


Table 7: Commercial Cellular Data System for Rail Order of Magnitude Costs 


Cellular Vendor Quantity Unit 
Rail Vehicles - Cellular Card (provide, install, commission) 566 EA 150 84,900 
Non-Revenue Vehicles - Cellular Card (provide, install, 
commission) 32 EA 150 S 4,800 
Central Site Equipment 1 EA 50,000 S 50,000 
Spares 1 LOT 10% | S 8,970 
Project Management, Eng., Overhead 1 LOT 30% | $ 41,910 
Training 9 | PERSONS 2,500 S$ 22,500 
Integration with CAD (Central Equipment) 1 LOT 100,000 | $ 100,000 
Integration with CAD (On-Board Equipment) 1 LOT 5,000 iS 5,000 
Warranty (5 Years + 5 Years Post-Warranty Call Support) 1 LOT 15% | $ 20,955 
Contingency 1 LOT 10% | $ 34,000 
Performance Bond 1 LOT 2% | S 7,000 
Consultant Costs Quantity Unit Unit Cost Extended Cost 
Engineering 1 LOT 
Implementation Support 1 LOT 
Contingency 1 LOT 
Agency Costs Quantity Unit 
Project Oversight 0.5 FTE iS 100,000 | $ 50,000 
Capital 
Subtotal Cellular Vendor 380,000 
Subtotal Consultant 84,000 
Subtotal Agency Costs 


Total 


Support Costs 

Quantity Unit 
Leased Data Communications 598 EA 1,076,400 
Leased Backhaul Circuits 1 EA 36,000 
System Maintenance 1 LOT - 
Agency Oversight (0.1 FTE for10 years) 0.1 FTE 100,000 


Total 
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5.1.4 Yard Management (Y.4 + Y.5) 


The following ROM costs for implementation of a Bus/Rail Yard Management System are based on the 
following assumptions: 


e Annual storage and server fee @ $1200/mo. 

° 1 FTE for 2 years for Metro project oversight, design, and implementation support. 
° 0.5 union FTE for 2 years for testing and support. 

e 0.5 union FTE for operation and maintenance. 

° Consultant support for design, specifications, and implementation support. 

e The cost is exclusive of taxes, freight, and any applicable duties. 


Table 8: Independent Yard Management Tool for Bus and Rail Order of Magnitude Costs 


Vendor Costs 


Hardware, Field Quantity Unit Unit Cost Extended Cost 
Additional Location Devices Buses 2450 EA S S 3,675,000 
Additional Location Devices Rail 566 EA 849,000 
Hardware, Backend & Infrastructure Quantity Unit Unit Cost Extended Cost 
In-house Data Aggregation & Yard 17 EA E 10,000 | § 170,000 
Comm Servers 

Software Quantity Unit Unit Cost Extended Cost 
Yard Management Software Core 1 LS 1,500,000 1,500,000 
Customization of Functions 1 LS 1,000,000 1,000,000 
Yard Setup 1 LS 600,000 600,000 
ATMS II Integration 1 LS 1,750,000 1,750,000 
Project Management Quantity Unit Unit Cost Extended Cost 
Project Management Staff 1 LS 100,000 100,000 
Design Reviews 1 LS 250,000 250,000 
Training 1 LS 100,000 100,000 
Acceptance Tests 1 LS 250,000 250,000 
Consultant Costs Quantity Unit Unit Cost Extended Cost 
Design and Specifications 1 LS S 50,000 S 

Implementation Support 1 LS S 50,000 

Agency Costs Quantity Unit Unit Cost Extended Cost 
Project Oversight, Design & 1 Ls $ 200,000 | $ 200,000 
Implementation Support (2 years) 
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Testing and Support (2 years) 0.5 EA | S 86,580 | S 43,290 


Capital Cost 


Subtotal Vendor Costs 10,244,000 
Subtotal Consultant Costs 100,000 
Contingency 10% 1,034,400 


Subtotal Agency Costs 243,290 


Total 
SS 


O&M 


Lease Costs Quantity Unit Unit Cost Extended Cost 
Cloud-based server 1 LS S 14,400 | S$ 14,400 


Support Costs Quantity Unit Unit Cost Extended Cost 


Vendor Annual Cost for Post Warranty 1 Ls é 512,200 
Hardware and software support 


Agency Maintenance Costs 0.5 LS 43,290 


10 Year O+M 
Total S 5,699,000 
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5.1.5 GPS + Track Wayside Circuits (TWC) and Beacons for Rail Vehicle Locations (T.4) 


The following ROM costs for implementation of a GPS, TWC, and beacon System for improved rail vehicle 
location predictions are based on the following assumptions: 


° 0.5 FTE over 1 year for Metro project oversight. 

° 1 union FTE over 1 year for Testing. 

° 0.5 union FTE for operation and maintenance. 

° The cost is exclusive of taxes, freight, and any applicable duties. 


Table 9: GPS with Track Wayside Circuits and Beacons Order of Magnitude Costs 


Vendor Costs 


Hardware, Field Quantity Unit Unit Cost Extended Cost 
Rail Car GPS Units 566 EA 1,500 849,000 
Rail Track Beacons 566 EA 500 283,000 
Hardware, Backend & Infrastructure Quantity Unit Extended Cost 
Track Wayside Circuits 20 EA 400,000 
Beacons 40 EA 180,000 
Hardware, Spares Quantity Unit Extended Cost 
Beacons 10 EA 

Software Quantity Unit Unit Cost Extended Cost 
Data fusion software 1 EA 200,000 200,000 
Project Management Quantity Unit Extended Cost 
Project Management Staff 1 LS 100,000 100,000 
Training 5% 10,000 
Acceptance Tests 10% 20,000 
Documentation 5% 10,000 
Warranty (Software) Quantity Unit Unit Cost Extended Cost 
Software (5 years) 5 LOT 5% 50,000 
Hardware (5 years) 5 LOT 1% 85,600 
Consultant Costs Quantity Unit Unit Cost 

Engineering 1 LS 

Implementation Support 1 LS 
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Agency Costs Quantity Unit Unit Cost Extended Cost 
S S 


Project Oversight 0.5 EA 100,000 
Testing/Install of TWC & Beacons 1 EA S 86,580 


Integration and interfaces 10% 


Subtotal Vendor Costs 2,252,600 


Subtotal Consultant Costs 125,000 


Contingency 237,760 


Subtotal Agency Costs 156,580 
Total 


O&M 

Support Costs Quantity Unit | Unit Cost Extended Cost | 
Vendor Annual Cost for Post Warranty 1 Ls e 56,315 e 56,315 
Hardware and software support 

Agency Maintenance Costs 0.5 EA S 86,580 S 43,290 


Hardware Refresh Costs (One Time) Quantity Unit Unit Cost Extended Cost 
Field hardware maintenance 1 LS S 225,260 One time 
10 Year O+M 
Total 940,000 
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5.1.6 Rail-specific Arrival Prediction Engine (T.5) 


The following ROM costs for implementation of a Rail Arrival Prediction System are based on the following 
assumptions: 


° 0.2 FTE over 1.5 years for Metro project oversight. 

e 0.05 union FTE over 1 year for testing. 

e 0.5 union FTE for operation and maintenance. 

° The cost is exclusive of taxes, freight, and any applicable duties. 


Table 10: Rail-specific Prediction Engine Order of Magnitude Costs 


Vendor Costs 


Software Quantity Unit 
Central System - New Prediction Engine 1 EA iS 200,000 S 200,000 

Project Management Quantity Unit 
Project Management Staff 0.5 LS iS 100,000 

Design Reviews 10% 

Training 5% 

Acceptance Tests 10% 

Documentation 5% 

Performance Bond 

Consultant Costs Quantity Unit 

Engineering 1 LS S 35,000 

Implementation Support 1 LS S 75,000 

Agency Costs Quantity Unit 

Project Oversight 0.3 EA S 150,000 

Testing 0.05 EA S 86,580 

Integration and interfaces 20% 
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Subtotal Vendor Costs 
Subtotal Consultant Costs 
Contingency 

Subtotal Agency Costs 
Total 


319,300 


110,000 


42,930 
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Support Costs Quantity Unit Unit Cost Extended Cost 


Vendor Annual Cost for Post Warranty 
Hardware and software support 


Agency Maintenance Costs 0.25 EA 


Total S 536,000 
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5.1.7 Public Address System Upgrade for Rail (T.9) 


The following ROM costs for implementation of a PA System Upgrade are based on the following 
assumptions: 


° 104 rail stations to be equipped. 

° 0.2 FTE over 3 years for Metro project oversight. 

° 0.05 union FTE over 1 year for Testing. 

° 0.5 union FTE for operation and maintenance. 

° The cost is exclusive of taxes, freight, and any applicable duties. 


Table 11: Public Address System Upgrade for Rail Order of Magnitude Costs 


Vendor Costs 


Hardware, Field Quantity Unit Unit Cost Extended Cost 
Station Upgrades 104 EA 1,040,000 
Hardware, Spares Quantity Unit Unit Cost 

Spares 5% 

Software Quantity Unit Unit Cost Extended Cost 
Central System 1 LS S 235,000 S 235,000 
Project Management Quantity Unit 

Project Management Staff 1 LS S 100,000 100,000 
Design Reviews 10% 23,500 
Training 5% 11,750 
Acceptance Tests 10% 23,500 
Documentation 5% 11,750 
Performance Bond 77,250 
Consultant Costs Quantity Unit Unit Cost Extended Cost 
Engineering 1 LS S 25,000.00 25,000 
Implementation Support 1 LS S 125,000.00 125,000 
Agency Costs Quantity Unit Unit Cost 

Project Oversight 0.6 EA 100,000 

Testing 0.05 EA 86,580 

Integration and interfaces 10% 
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Subtotal Vendor Costs 1,574,750 

Subtotal Consultant 150,000 
Costs 

Contingency 172,475 


Subtotal Agency Costs 87,829 


Total 


Support Costs Quantity Unit Unit Cost Extended Cost 


Vendor Annual Cost for Post 
Warranty Hardware and software 157,475 
support 


Agency Maintenance Costs 0.5 EA 43,290 


10 Year O+M 


Total $ 2,008,000 
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5.1.8 Multi-modal Alerts System (T.3) 


The following ROM costs for implementation of an Improved Service Alerting System are based on the 
following assumptions: 


e Cloud-based service cost of $1200/mo. is assumed. However, the Alert System could be run 
on existing Metro servers. 


° 0.2 FTE over 3 years for Metro project oversight. 

° 0.05 union FTE over 1 year for Testing. 

° 1 union FTE for operation and maintenance unless cloud-based service is used. 
e The cost is exclusive of taxes, freight, and any applicable duties. 


Vendor Costs 


Table 12: Multi-modal Alerts System Order of Magnitude Costs 


Software Quantity Unit 
Central System Upgrades 1 EA 
Project Management Quantity Unit 
Project Management Staff 0.3 LS S 100,000 

Design Reviews 5% 

Training 10% 

Acceptance Tests 5% 

Documentation 5% 

Performance Bond 

Consultant Costs Quantity Unit 
Engineering 1 LS S 30,000 S 30,000 
Implementation Support 1 LS S 45,000 S 45,000 

Agency Costs Quantity Unit 
Project Oversight 0.6 EA 100,000 

Testing 0.05 EA 86,580 

Integration and interfaces 1 LS 30,000 
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Subtotal Vendor Costs S 
Subtotal Consultant Costs S 75,000 
Contingency 10% S 49,200 
Subtotal Agency Costs S 94,329 
Total $ 636,000 
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Lease Costs Quantity Unit Unit Cost Extended Cost 
Cloud-based server 12 MOS S 1,200 | $ 14,400 
Support Costs Quantity Unit Unit Cost Extended Cost 
Vendor Annual Cost for Post 
Warranty Hardware and software 
support 
Agency Maintenance Costs 0.5 EA 
10 Year O+M 
Total S 1,027,000 
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5.1.9 Enhanced Multi-modal Aggregation System with Single GTFS-realtime Feed (T.6) 


The following ROM costs for implementation of Traveler Information Aggregation System are based on the 
following assumptions: 


° Cloud-based service cost of $2400/mo. is assumed. However, the Aggregation System could 
be run on existing Metro servers 


° .2 FTE over 2 years for Metro project oversight. 

° 0.05 union FTE over 1 year for Testing. 

° 1 FTE over 1 year for Integration and Interfaces 

e 0.5 union FTE for operation and maintenance. 

e The cost is exclusive of taxes, freight, and any applicable duties. 


Table 13: Enhanced Multi-modal Aggregation System with Single GTFS-realtime Feed 


Vendor Costs 


Software Quantity Unit Unit Cost Extended Cost 


System Upgrades - Aggregation 1 LS S 850,000 850,000 


System Upgrades - GTFS-realtime Feed 1 LS S 100,000 100,000 


Project Management Quantity Unit Unit Cost Extended Cost 


Project Management Staff 1 LS S 


Design Reviews 


Training 


Acceptance Tests 


Documentation 


Performance Bond 


Consultant Costs Quantity Unit 

Engineering 1 LS S 95,000 95,000 

Implementation Support 1 LS S 142,500 142,500 

Agency Costs Quantity Unit 

Project Oversight 0.4 EA S 100,000 40,000 

Training - 

Testing 0.05 EA 86,580 4,329 

Integration and interfaces 1 LS 150,000 150,000 
Subtotal Vendor Costs S 1,287,000 
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Subtotal Consultant Costs 


Contingency 


Subtotal Agency Costs 


Total 


237,500 


152,450 


194,329 


Lease Costs Quantity Unit Unit Cost Extended Cost 

Cloud-based server 12 MOS S 2,400 S 28,800 

Support Costs Quantity Unit Unit Cost Extended Cost 

Vendor Annual Cost for Post Warranty ‘ YR § 64,350.00 64,350 

Hardware and software support 

Agency Maintenance Costs 0.3 EA S 86,580 25,974 
Total 


September 2016 


104 


BUS AND RAIL FLEET SYSTEMS STRATEGIC PLAN 
Prepared for Los Angeles Metropolitan Transportation Authority by EIGER TechSystems 


5.1.10 Webpages with Real-time Passenger Information (T.7) 


The following ROM costs for implementation of upgrades to the existing Metro web page for improved 
real-time passenger information are based on the following assumptions: 


e No additional cost for cloud-based service, as current hosting service will be used. However, 
the Dissemination System could be run on existing Metro servers. 


e 0.1 FTE over 1 year for Metro project oversight. 

° 0.05 union FTE over 1 year for Testing. 

° 0.25 FTE over 1 year for Integration and Interfaces 

e 0.5 union FTE for operation and maintenance. 

e The cost is exclusive of taxes, freight, and any applicable duties. 


Table 14: Webpages with Real-time Passenger Information Order of Magnitude Costs 


Vendor Costs 


Software Quantity Unit Unit Cost Extended Cost 


System Upgrades 1 EA S 150,000 S 150,000 
Project Management Quantity Unit Unit Cost Extended Cost 
Project Management Staff 1 LS S 40,000 

Design Reviews 10% 

Training 5% 


Acceptance Tests 10% 


Documentation 5% 


Performance Bond 


Consultant Costs Quantity Unit Unit Cost Extended Cost 


Engineering 1 LS S 20,000.00 S 20,000 
Implementation Support 1 LS S 40,000.00 S 40,000 
Agency Costs Quantity Unit 

Project Oversight 0.1 EA 100,000 
Testing 0.05 EA 86,580 
Integration and interfaces 0.25 EA 150,000 

Subtotal Vendor Costs S 239,700 

Subtotal Consultant Costs S 60,000 

Contingency 10% | $ 29,970 
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Support Costs 


Subtotal Agency Costs 


Total 


Quantity 


Unit 


Agency Maintenance Costs 


0.5 
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Total 


$ 51,829 


$ 381,000 


Unit Cost Extended Cost 


$ 86,580 . 43,290 


10 Year O+M 
$ 433,000 
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5.1.11 | NTCIP-compliant Signs with Common Sign Control (T.8) 


The following ROM costs for implementation of NTCIP-compliant signs at rail and bus stations and park- 
and-rides with a common sign control are based on the following assumptions: 


e 88 new signs. (85% of 104 signs) It is assumed that 15% are already compliant. 
e Unit cost assumes two signs per platform and two platforms per station. 

° 0.5 FTE over 2 years for Metro project oversight. 

° 0.1 union FTE over 1 year for Testing. 

° 0.25 FTE over 1 year for Integration and Interfaces 

e 1 union FTE for operation and maintenance. 

° The cost is exclusive of taxes, freight, and any applicable duties. 


Table 15: NTCIP-compliant Signs with Commons Sign Control Order of Magnitude Costs 


Vendor Costs 


Hardware, Field Quantity Unit Unit Cost Extended Cost 
Signs & Associated Control Unit/Comm 88 EA 50,000 | $ 4,400,000 
Hardware, Spares Quantity Unit Unit Cost Extended Cost 
5% | S 220,000 
Software Quantity Unit Unit Cost Extended Cost 
Central System Upgrades 1 LS S 300,000 | S$ 300,000 
Interface with Existing Metro TDB & Systems 1 LS S 250,000 | $ 250,000 
Project Management Quantity Unit Unit Cost Extended Cost 
Project Management Staff 1 LS S 150,000 150,000 
Design Reviews 15% 45,000 
Training 5% 15,000 
Acceptance Tests 10% 30,000 
Documentation 35% 105,000 
Performance Bond 177,800 
Consultant Costs Quantity Unit Unit Cost Extended Cost 
Engineering 1 LS S 120,000 | S 120,000 
Implementation Support 1 LS S 250,000 | S$ 250,000 
Agency Costs Quantity Unit Unit Cost Extended Cost 
Project Oversight 1 EA S 100,000 | $ 100,000 
Testing 0.1 EA S 86,580 | S 8,658 
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Integration and interfaces 0.25 EA | S 150,000 | S$ 37,500 


Subtotal Vendor Costs 5,692,800 
Subtotal Consultant Costs 370,000 
Contingency 10% 606,280 

Subtotal Agency Costs 146,158 


Total 6,815,000 


Support Costs Quantity Unit | Unit Cost Extended Cost | 
Vendor Annual Cost for Post Warranty 5% | § 284,640 
Hardware and software support 

Agency Maintenance Costs 1 EA S 86,580 | S 86,580 
Hardware Refresh Costs Quantity Unit | Unit Cost Extended Cost | 
Equipment lifecycle replacement/upgrades 1% |S 68,150 


10 Year O+M 
Total S 4,394,000 
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5.1.12 Video Streaming for Bus and Rail (V.3 + V.4) 


The following ROM costs for implementation of a Video Streaming System are based on the following 
assumptions: 


e S5 per month per vehicle for cellular bandwidth. 

e Cloud-based service for caching. 

° 1360 buses will require a new network video recorder 

e 0.1 FTE over 10 years for Metro project oversight. 

° The cost is exclusive of taxes, freight, and any applicable duties. 


Table 16: Video Streaming for Bus and Rail Order of Magnitude Costs 


Vendor Cost: Hardware, Field Quantity Unit Unit Cost Extended Cost 
Network Video Recorder 1360 EA 4,500 S 6,120,000 


Total $ 6,120,000 


Support Costs Quantity Unit Unit Cost Extended Cost 
Vendor Annual Cost for Post Warranty 612.000 
Hardware and software support ’ 

Cellular Costs 10 EA 217,440 2,174,400 
Agency Maintenance Costs 10 EA 15,000 150,000 


Caching 10 EA 2,160 21,600 


Total 
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5.1.13 SCADA Maintenance HMI (S.4) 


The following ROM costs for implementation of a SCADA Maintenance HMI System are based on the 
following assumptions: 


° Cost assumes existing ARINC software used. 
° 0.2 FTE over 2 years for Metro project oversight. 
° The cost is exclusive of taxes, freight, and any applicable duties. 


Table 17: SCADA Maintenance HMI Order of Magnitude Costs 


Vendor Costs 


Hardware, Backend & Infrastructure | Quantity Unit 
SCADA Servers 4 EA 1,939 7,756 
SCADA Client Workstations 10 EA 1,779 17,790 
Hardware, Spares Quantity | Unit 
SCADA Servers 1 EA S 1,939 1,939 
SCADA Client Workstations 1 EA S 1,779 1,779 
Software Quantity Unit 

Build Maintenance Oriented Graphics 1000 HRS 

Project Management Quantity Unit 

Project Management Staff 800 EA 120,000 
Project Management Meetings 208 EA 31,200 
Design Reviews 96 EA 14,400 
Training 160 EA 24,000 
Acceptance Tests 480 EA 72,000 
Documentation 480 EA 72,000 
Consultant Costs Quantity Unit 
Engineering 200 EA S 30,000 
Implementation Support 100 EA 150 S 15,000 
Agency Costs Quantity Unit 

Project Oversight 0.4 EA 100,000 

Training 400 EA 150 

Testing 200 EA 150 

Contingency 200 EA 150 
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Subtotal Vendor Costs 
Subtotal Consultant 
Costs 


Contingency 


Subtotal Agency Costs 


Total 


Support Costs Quantity Unit 

Vendor Annual Cost for Post Warranty 

Hardware and software support 10 EA 

Hardware Refresh Costs Quantity Unit 

Server replacements after 5 years 1 EA 
Total 
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462,864 


Unit Cost Extended Cost 


$ 10,000 S 100,000 


Unit Cost Extended Cost 


$ 5,109 5,109 


10 Year O+M 
S 105,000 
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5.1.14 


SCADA Message Gateway 


The following ROM costs for implementation of a Message Gateway System are based on the assumption 
that there will be 0.2 FTE over 2 years for Metro project oversight. The cost is exclusive of taxes, freight, 


and any applicable duties. 


Table 18: SCADA Message Gateway Order of Magnitude Costs 


Vendor Costs 


Hardware, Backend & Infrastructure Quantity Unit | Unit Cost Extended Cost | 
Message Server 2 EA S 1,939 S 3,878 
Hardware, Spares Quantity Unit | Unit Cost Extended Cost | 
SCADA Servers 1 EA S 1,939 S 1,939 
Software Quantity Unit | Unit Cost Extended Cost | 
Build alarm database / Configure 400 HRS S 100 S 40,000 
Software License 2 EA S 2,700 S 5,400 
Project Management Quantity Unit | Unit Cost Extended Cost | 
Project Management Staff 200 EA S 150 S 30,000 
Project Management Meetings 4o EA S 150 S 6,000 
Design Reviews 40 EA S 150 $ 6,000 
Training 160 EA $ 150 $ 24,000 
Acceptance Tests 200 EA S 150 S 30,000 
Documentation 200 EA S 150 S 30,000 
Consultant Costs Quantity Unit | Unit Cost Extended Cost | 
Engineering 200 EA S 150 S 30,000 
Implementation Support 100 EA S 150 S 15,000 
Agency Costs Quantity Unit | Unit Cost Extended Cost | 
Project Oversight 0.4 EA $ 100,000 $ 40,000 
Training 400 EA S 150 S 60,000 
Testing 200 EA S 150 S 30,000 
Contingency 200 EA $ 150 $ 30,000 
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Subtotal Vendor Costs 
Subtotal Consultant Costs 
Contingency 


Subtotal Agency Costs 


Total 


177,217 


160,000 


$ 397,000 
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Support Costs Quantity Unit 

Vendor Annual Cost for Post Warranty 

Hardware and software support 1 EA 

Hardware Refresh Costs Quantity Unit 

Server replacements after 5 years 1 EA 
Total 
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Unit Cost Extended Cost 


$ 405 S 405 


Unit Cost Extended Cost 


S) 776 S 776 


10 Year O+M 
ls 42,000 
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D2 Bundling of Costs 


There are some opportunities for cost reduction if certain projects are implemented concurrently. By 
running the voice and data communications for bus and the data communications and Improved 
Prediction for Rail projects in parallel with the ATMS II Bus and Rail project, there could be a reduction of 
$8.1 M in duplicated integration costs as well as the potential reduction of duplicate hardware. Other 
areas of potential cost reductions would be software development costs for Rail AVL, Arrival Prediction, 
Improved Service Alerting, and Traveler Information Aggregation if run in parallel with the ATMS II project. 
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6 Technology Trends and Impacts 


When Metro commenced the deployment of its 
Advanced Transportation Management System 
(ATMS) computer aided dispatch/automated vehicle 
location (CAD/AVL) system, it was a state-of-the-art 
integration of Information Technology (IT), mobile 
communications, and on-board systems. CAD/AVL 
systems have continued to evolve since that time, 
however, and many things are technically feasible for 
the transit industry that were not options when the ATMS was deployed by Metro. Furthermore, some of 
these technology trends have been adopted from other uses and were not developed originally or 
specifically for transit use. 


This section discusses technology trends that 
will impact the recommended projects and 
future projects. The technology trends will 
allow Metro to more easily and cost 
effectively implement future technologies. 


Many of the following central system and IT technology trends have already been adopted and are heavily 
utilized by Metro for both its bus and rail fleets since ATMS was first implemented including: 


e Virtualized environments 

° Cloud computing/services 

e Software as a service 

° Off-site server/application hosting 

e Enhanced database interface tools 

° Enhanced reporting and business intelligence (BI) tools 


These trends will have substantial impact on the design of ATMS Il, the on-board systems architecture, 
voice and data communications, and supporting systems that are recommended in this Strategic Plan. It is 
important to understand these trends as shifts and advances will likely impact the risks and costs 
associated with most of the recommended projects. 


6.1 Looking to the Future 


This Strategic Plan should be a living document and updated periodically—every five years or when Metro 
priorities and funding changes and to reflect new technology trends. Revisions to this Strategic Plan should 
incorporate findings from Metro’s IT Strategic Plan and Metro’s Strategic Plan for the entire agency, which 
are currently under development. Other regional ITS strategic plans should be considered at that time as 
well. In addition, updates to the Strategic Plan should account for ITS projects by Metro and other 
regional agencies that have been completed, in progress, or planned. IT systems should be 
updated/upgraded every five years and hosted and Software as a Service solutions should be considered 
at that time. 


The following are some forward-looking trends that will influence the Strategic Plan as it is updated over 
the course of the next 15 years: 


° More of an Internet of Things- (loT-) type environment on the transit vehicle where devices 
and applications may become less centralized around the intelligent vehicle unit/vehicle 
logic unit (IVU/VLU). It is likely that either the MDT or the MGR would include functionality 
to support on-board data storage and supplemental processing needs, in addition to serving 
its primary function. An example would be a vehicle health monitoring (VHM) device that 
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would internally process and communicate key information to/from other devices, such as 
the MDT and the AVL devices. While this may seem a step back from the architecture 
centralized around a central IVU/VLU, it actually opens up transit vehicle architectures to 
transition and progress in a smoother and more logical fashion, as well as prevents agencies 
from being tied to a single integration vendor. 


° Devices will be swappable and less dependent on make/model, so that, while there will still 
be variations in capabilities, it would not require a major integration effort to include new 
devices into the on-board architecture. 


e At this point, it is anticipated that there will be much wider adoption of commercial industry 
standards. These might include AVL, fare payment, video, and display technologies. 


e Commercial cellular, or in some cases public agency, data networks will be the primary mode 
of voice and data communications. Land mobile radio (LMR) solutions may be retained in 
some cases for fallback but are anticipated to phase out as they reach their lifecycle 
replacement timeframes. 


° Edge device or “fog computing” comes 
into play with data processing being 
pushed to the edge of the on-board 
network environment and possibly vA \ 

Fog 


involving multiple devices. For example, 

automated passenger counter (APC) ne Cr 
data is currently heavily post-processed / ] \ 
once downloaded from the vehicles. In = 
the future, with improved sensors and 

the loT-type approach, the processing Fae 


will occur within the APC device itself with comparisons of passenger counts from enhanced 
video solutions for validation purposes. 


Core 


Edge 


° In addition to what is occurring largely from the IT and communications industries, there is a 
major push in North America and throughout parts of Asia and Europe for enhanced 
connected vehicle applications. While these originally focused on independent vehicle safety 
and vehicle-to-vehicle applications, the trends are expanding to include vehicle to roadside 
infrastructure applications. These include safety, signal control, controlled access, emissions 
monitoring, customer information, and many other applications that could be used by the 
transit industry. 


° Increasingly, trends to support smart growth and sustainable development are including 
potential technology applications at multi-modal hubs. This includes tying together 
information from fleet systems to provide input and synergies with other modes at these 
hubs. Common methods of payment are increasingly being discussed, as well as more 
detailed wayfinding and customer-specific information. For example, a commuter express 
bus arriving at a mobility hub might customize information for alighting passengers and 
provide context-sensitive information they are likely to desire. While this area is still 
conceptual, it highlights the general trend of substantially increasing demands on fleet 
management systems for timely and accurate information. 


Figure 8 below summarizes these trends in five basic categories with the following tables providing 
additional background associated with the individual elements labelled in the figure. 
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Figure 8: Anticipated Transit Technology Trends 
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(O) On-Board Systems Trends 


O01 


Ethernet/IP On-Board Mobile Gateway Router (MGR) — 


The expansion of IT-like network environments is 


already established with a widespread move in transit fleet systems to cellular data networks, on-board 
MGRs acting as communications/networking devices, and the increasing number of on-board devices that 
offer Ethernet connections and IP addressing schemes. This allows agencies to manage the on-board devices 
similar to how IT professionals manage office networks. It simplifies monitoring, maintenance, and upgrades, 
as well as significantly expands communications options and flexibility. It also allows for Wi-Fi connections 
between vehicles and backend systems to be optimized. Metro has already deployed pilots with this type of 
equipment, and has included it in its new bus procurement specifications. This is a starting point that can be 
built-upon as part of the new more open architecture that would be implemented as part of the Connected 
Fleet Vehicles & Facilities project being undertaken by Metro and the recommended ATMS II project. The 


Current 
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(O) On-Board Systems Trends 


push should be for all possible devices on-board to move to this Ethernet/IP type mobile network 
environment. 


02 
5 Years 


Shift to Off-Board Logic Functions with High Capacity Data — The emergence and adoption of cost effective 
high capacity cellular data capabilities for transit agency use are changing the perspective on what functions 
need to occur on-board a vehicle versus those that can occur in the “cloud” or backend systems. For example, 
due to historic data communications limitations CAD/AVL systems generally focused schedule adherence and 
comparison functions on-board the vehicles that require significant scheduling data and processing 
functionality on-board. As commercial cellular data options have offered high-quality coverage and data 
throughput, the shift is starting to move more functions off the vehicle and into the back office applications 
environment. This trend will continue consistent with what is being seen in the rapid expansion of intelligent 
devices and the “Internet of Things” in the consumer electronics and logistics industries. 


Open Platform Intelligent Vehicle Unit/Vehicle Logic Unit (IVU/VLU) — Historically CAD/AVL and transit on- 
board systems were highly proprietary including both the on-board software, hardware, and sometimes even 
the connections between devices. Due to changes in the broader electronics industry, widespread adoption 
of fleet management functions in logistics/trucking, and the increasing cost-competitiveness of electronic 
manufacturers, there is a broader range of hardened mobile computing devices that can operate and survive 
in bus or rail vehicle environments. The entry of automotive and heavy vehicle manufacturers into the broad 
adoption of more robust and upgradeable on-board electronics for information and entertainment means 
that more common and robust operating systems and development platforms for on-board exist today than 
ever before. Already interchangeable on-board computers exist that serve as IVU/VLUs for several CAD/AVL 
vendors, and Metro’s replacement for ATMS should be centered on a more open IVU/VLU platform that is 
not tied to a single vendor. The comparative example would be similar to a desktop computer which can be 
purchased from several different manufacturers and installed with software applications developed by a 
variety of vendors all running on a common operating system. 


03 
10 Years 


On-Board Device to Device “Edge Logic” — A little further out is the pushing of the intelligence from the single 
IVU/VLU to the individual on-board devices. In an on-board networked environment, each of these devices 
would contain some intrinsic intelligence and would also be capable of sharing information to provide a more 
accurate and comprehensive set of data on the mobile transit environment. These types of devices and 
applications require the newer loT type environment and will take several years to emerge in the transit 
marketplace. This means pushing for this in the on-board architecture for Metro was not realistic given the 
timeline for ATMS Il. 


04 
15 Years 
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Direct loT Vehicle Devices to Cloud Service Widespread — Ultimately, the traditional model of mobile vehicles 
communicating to a central CAD/AVL or related fleet management system will fade away. Widespread use 
of direct communications from mobile devices to applications residing in cloud services (e.g. Amazon Web 
Services, Microsoft Azure Cloud Services, etc.) will reach the transit industry on a widespread basis. This will 
allow transit agencies to deploy common mobile devices on vehicles, and establish direct communications 
from the vehicles to the “cloud” where any number of applications and functionalities could be running. The 
ability to easily expand fleet deployments, upgrade backend applications, and provide true “big data” 
analytics will be fully realized in this environment. 
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VV) Connected Vehicles 


Cv1 
Current 


Original Equipment Manufacturer (OEM) Safety Systems — Bus manufacturers are currently providing options 
for driver support and safety systems, such as forward collision warning, blind-spot vehicle detection, lane 
guidance support, etc. Most of these systems are selected for their ability to support driver safety, and some 
are deployed in special applications, such as freeway shoulder running or transit guideway operations. These 
systems are currently widely deployed in the consumer automotive and trucking industries to offer similar 
safety advantages. Some available features, such as adaptive cruise control, are not typically applicable for 
agencies such as Metro offering fixed route bus services. 


Connected Vehicle (CV) Pilots - A number of connected vehicle pilots are being implemented as part of 
USDOT’s national program efforts. These include a range of functions, including using CV for bus signal 
priority (BSP), supporting dynamic rideshare functions, improving customer information based on enhanced 
bus to roadside communications, etc. It should be noted only some of these applications rely on dedicated 
short range communications (DSRC) equipment, which operates in the 5.9 GHz band. There are also a 
number of Vehicle to Vehicle (V2V) applications in testing that provide an interconnected network of vehicles 
communicating with each other along a roadway corridor. As CV applications become more widespread in 
the general transportation environment, transit fleets will need to be part of this equation in order to make 
effective use of transit-specific as well as broader CV functionality. 


cVv2 
5 Years 


Transit Vehicle to Infrastructure (V2I) Applications — As follow-up to the Connected Vehicle pilots, it can be 
anticipated that within the next five years more mainstream CV applications will appear for BSP, dynamic 
rideshare, and transit access and guideway control and monitoring. 


Autonomous Bus Operations Pilots — Within five years several examples of autonomous bus operations pilots 
in guideways or semi-mixed operations should be in place. One example is the proposed autonomous bus 
operation pilot proposed for the recently awarded Columbus Smart City efforts. 


cv3 
10 Years 


Connected Vehicle Based Prioritization of Traffic in Corridors (Pilots) — This would be an early effort to 
demonstrate the ability to prioritize some types of traffic (e.g. transit and freight in some circumstances) in 
the overall equation of V2V vehicle networks and throughput along a corridor. Actual implementation of this 
would require a substantial set of private automobiles in a test corridor to also be CVs, but the early examples 
might dictate lane positions for vehicles based on the presence of buses (transit receiving priority). 


Autonomous Bus Operations (Specific Facilities) - Early autonomous bus operations are likely to occur in 
guideways or dedicated bus lanes and facilities. They may also occur in environments that have been 
engineered to support autonomous bus operations in mixed flow operations. An example might be an 
autonomous circulator bus in a downtown environment running in marked bus lanes. 


CVv4 
15 Years 
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Transit Prioritization in Corridor Throughput — In the next 15 years, it is likely that CV applications will be much 
more common on the entire vehicle fleet (including private autos). This will create an environment where all 
the vehicles are communicating with one another and with specific roadside functions (e.g. signals, high 
occupancy vehicle (HOV) lane enforcement, etc.). This will allow for widespread implementation of 
algorithms and strategies focused on maximizing and promoting transit in the overall flow and throughput 
of a corridor. This will be most effective in fully autonomous environments. 


Autonomous Bus Operations (Regular Routes) — The rapid progression of autonomous cars and trucks will 
eventually lead to more widespread use of autonomous buses. As driverless vehicles are already in test 
operations in real traffic conditions in several places in the US, autonomous bus operations in mixed traffic 
flow should be expected to expand from this period forward. 
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(CA) CAD/AVL Solutions 


CA1 e Hosted Solutions — Many transit agencies have been exploring variations of hosted solutions and 
Current environments, where they own the applications but they are actually managed and hosted by contracted 
vendors. These options in the past have been more advantageous for smaller fleets with more limited fleet 
system functionality, but this is starting to shift. Metro already uses hosted server services for some 
applications. These offer the advantage of allowing rapid adjustments to the computing power and 
capabilities available as the agency’s needs may change. As another example, AC Transit is deploying its 

CAD/AVL core system functionality at a primary and secondary hosted data center. 


CA2 e Functions Shift to Back Office-Focused Solutions — As commercial cellular data options have offered high- 
5 Years quality coverage and data throughput, the shift is starting to move more functions off the vehicle and into 
the back office applications environment. It is much easier to deal with modifications and functional 
enhancements on the back office solution when the on-board architecture is simplified. As an example, with 
high-frequency reliable communications, schedule adherence calculations for individual vehicles could be 
made by back office solutions rather than on-board the vehicle. These approaches are begging to appear, 

particularly related to rail operations, schedule adherence, and prediction calculations. 


e On-Demand Services — Increasingly agencies are looking for their fleet management and CAD/AVL systems to 
support more flexible transit services. While some pilot projects and efforts have been undertaken, the ability 
and need to support demand driven transit services will increase. This could include options such as flex- 
routing and shifting interlining services and trippers to accommodate areas and platforms exhibiting 
unusually high passenger demands. 


CA3 e —_ Large Scale CAD/AVL Software as a Service (SaaS) — Some transit agencies have moved from considering SaaS 
10 Years as a concept for supporting external elements of their fleet management system to including this 
consideration as a part of their evaluation of a CAD/AVL system replacement. While this has been common 
for smaller fleets, it is now emerging as a serious consideration for medium- to larger-sized transit fleets. 
Most vendors are not currently properly positioned to support major fleet management solutions as a SaaS, 
but this is expected to change with time. In about another 10 years, larger agencies may be able to approach 

a variety of fleet systems needs as a pure SaaS. 


e Widespread Open Source Use — Properly utilizing open source solutions for fleet applications has been 
historically difficult. Currently, a variety of transit information applications and coding resources reside in 
open source environments. TriMet is currently moving toward deploying an loT Mobile Gateway that would 
support some open source applications for light rail use. The existing basis of open source software for transit 
customer information, arrival prediction, and fleet management solutions will slowly expand over time. If 
Metro maintains an open IVU/VLU platform and properly architectures the on-board environment, then they 
should be able to capitalize on some of these open source solutions for enhanced fleet functionality and 
customer information applications over time. 


CA4 e Shift to Predictive Schedules — Schedules are currently largely static and entered well in advance by skilled 
15 Years transit schedulers/planners. Some services operate on headways but are still subject to assumptions and 
estimations about the run times between time points. There are some rudimentary feedback processes to 
assist schedulers in refining timetables with current systems. This process will eventually become much more 
flexible and based on predictive modeling. Using much more frequent vehicle position updates and reporting 
to the CAD/AVL system and leveraging Business Intelligence and “Big Data” tools, systems will be able to 
supply accurate trends and seasonal variations in enough detail to automatically adjust the underlying transit 
schedules at set intervals with the input and guidance of skilled schedulers. 
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VD1 
Current 


Commercial Cellular Use — With the current generation of CAD/AVL and fleet management systems, the use 
of commercial cellular data is widespread. This has been supported by lower cost data plans, commercial 
pooled data options, and aggressive pricing by competing cellular providers. Some recent examples of 
commercial cellular data use for CAD/AVL include RTD (Denver), AC Transit (Oakland), Foothill Transit, and 
many others. In addition, many transit agencies are moving to Voice over Internet Protocol (VoIP) solutions 
built on commercial cellular data networks. 


VD2 
5 Years 


LA-RICS Broader Build-out —Metro is currently reviewing LA-RICS coverage and services in a test effort with a 
single vehicle. The Communications Plan (part of this Strategic Plan) discusses comparing commercial cellular 
data and LA-RICS for costs, coverage, and performance. It can be assumed that over time, LA-RICS coverage 
may improve. Utilizing an on-board architecture with a flexible MGR will allow for Metro to determine which 
options best suit its needs over time and adjust as appropriate. 


5G Cellular — Currently most CAD/AVL and fleet systems on commercial cellular data operate on a 3G or 4G 
network. Within five years, 5G commercial cellular networks should become available, while 4G networks 
will likely remain active for some period beyond widespread 5G implementation. Again, the use of a flexible 
MGR will allow Metro to update cellular communications as needed. 


VD3 
10 Years 


Large Scale Reduction of LMR Systems for Transit Use — Many agencies that are moving to cellular data are 
considering VoIP solutions for voice. Most are retaining their current LMR voice radio systems (and 
sometimes data systems) as fallback or redundant solutions for the foreseeable future. Eventually these 
systems will reach their end of useful life and will require replacement or will be phased out. 


Flexible Data Switching Widespread — MGRs allow for switching between various Wi-Fi and cellular data 
options depending on configuration, signal strength/related factors, and communications options. The 
switching process is still somewhat rudimentary and requires that data connections and communications be 
re-established resulting in lost or re-sent data. The flexibility of the MGRs to switch between a variety of 
communications solutions on the fly is expected to significantly improve within the next decade, further 
enhancing the communications flexibility and options available for fleet systems. 


FirstNet (First Responder Network Authority) — FirstNet is a national effort to roll-out a broadband data 
network for emergency services. This is similar to a commercial cellular network, but it would be available 
exclusively to public safety agencies (transit is generally classified as public safety). It is possible LA-RICS could 
become the region’s implementation of FirstNet. 


(T) Traveler Information 


T1 
Current 


Enhanced Arrival Prediction Engines — Much improved bus and rail arrival prediction engines are becoming 
available as agencies substantially improve the frequency of their vehicle location updates and leverage 
newer cellular data communications. 


GTFS & GTFS-realtime — GTFS is a widely deployed data format for transit schedule data across the nation, 
and its widespread use provides support for a wide range of customer information applications. Also, many 
agencies have or are rolling out real-time vehicle location and alerts updates in a GTFS-realtime format as 
they deploy or update their CAD/AVL systems. 


Standardized Traveler Information Interface — Metro already provides a developer portal for access to Metro 
transit information to support the outside development of customer information applications. This is 
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Traveler Information 


becoming a widespread practice for transit agencies, and the standardized interfaces and developer portal 
should be updated as ATMS Il is deployed and provides enhanced information. 


T2 e = Multi-Mode/Anymode Mobile Apps — Many smartphone applications provide links to separate apps for 
5 Years transit, auto, ridesharing, and related applications. However, they generally do not provide well integrated 
solutions for users that seamlessly allow movement between modes with scheduled and real-time 
information and status. Within the next few years this will significantly change as various modal service and 
information providers pair up and support each other’s information in a more integrated fashion. 


e Projected Displays (full daylight) — Projected displays have the advantage of being able to provide more 
location specific data and improved wayfinding, but current units do not operate in full daylight. 
Improvements in this arena should reduce costs and improve daylight performance of these devices that 
could then be more widely utilized for transit and multi-modal applications. 


e Personalized Wayfinding — Wayfinding with smartphone applications is already widely available for a variety 
of purposes, but over the next few years this will become more closely tied to available displays and 
wayfinding indications located in the physical environment. For example, a customer might set a destination 
that includes using rail to reach a stop, and then routes them to a car-sharing location. 


73 e Complete Smartphone Penetration of Transit Users — Statistics and surveys are showing that the younger 
10 Years generations are broadly adopting smartphone use regardless of income levels. Within the next ten years, 
inexpensive data plans and smartphones, combined with the natural transitions of social trends will mean 
the vast majority of transit users will have access to and use a smartphone. This has implications for current 

and future plans for providing fair and equitable customer information to the full range of transit users. 


4 e = Trip Pattern Recognition/Anticipation Intelligence for Transit Users — Already smartphone applications can 
15 Years anticipate typical trips you make on a frequent basis; however, these types of features are generally not 
multi-modal and do not readily tie into real-time transit information and service alerts. Instead of people 
having to subscribe to route alerts or using a variety of applications and services, the combined traveler 
information solution will anticipate a complex pattern of trip making; recognize traffic, transit, parking, and 

related conditions; and make appropriate recommendations, alerts, and adjustments. 


6.1.1 Connected Vehicles 


Figure 9 displays an anticipated timeline for the emergence of autonomous and connected vehicle 
functionality. 
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Figure 9: Anticipated Timeline for Transit Autonomous and Connected Vehicles 


It should be noted that there are currently two distinct meanings for the “connected vehicle” terminology 


Autonomous & V-to-V Functions trans LA Metro Suggested Actions 


AVI 
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Driverless Circulator Shuttles / Services 
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Routes 
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Signal Priority Bus / Rail 


Dynamic Rideshare 


Dynamic Bus Bay Assignments 


vi2 


Managed Reversible Transitways 


Dynamic / Variable Use Transit Lanes 
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Build Transit Facilities with V-to-I / Comm 
Infrastructure 


SA1i 
Connected Bus / Rail Projects with MGR 


New Bus Procurements with OEM Vehicle 
Safety Systems 
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Architectures 


SA2 


Plan for Autonomous Bus / Rail Operations 


SA3 


Work with Cities / Partner Agencies to 
Prioritize Transit Throughput 


SA4 


Design and Implement for Autonomous Bus 
/ Rail Operations 


at Metro. Connected fleet vehicles, connected buses, or connected rail is used in discussing Metro fleet 
and communications systems to refer to the deployment of MGRs and cellular data communications on 
the fleet vehicles. More broadly, “connected vehicles” refers at a national and international level to 
discuss a series of concepts that represent a variety of communications, vehicle to vehicle (V2V) 
networking, and vehicle to infrastructure (V2I) connectivity and functionality. Autonomous vehicles are a 
specific set of functions that interrelate with connected vehicles and are focused on an increasing level of 
vehicle autonomy from direct driver input and control. Autonomous and connected vehicle functions are 
important to consider as they represent the following: 
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Many connected vehicle functions have direct links to recommended fleet systems, 
particularly on-board equipment and components. 


Autonomous buses will play an increasing role in the future of transit operations beginning 
with enhanced driver safety systems and ultimately leading to increasing options for fully 


autonomous operations. 


Significant pending changes to the broader transportation and mobility environment will 
directly impact how transit operates and interrelates with other traffic and modes. 
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e There will be substantial federal and other funding opportunities for autonomous and 
connected vehicle applications that Metro will need to be involved in to maintain its 
competitiveness. 


e Smart City set of technology and communications applications will be emerging over the 
next 15 years. 


The following tables discuss major autonomous and connected vehicle trends illustrated in Figure 9 over 
the next fifteen years and beyond. The final table lists suggested actions for Metro. 


ee TREND DESCRIPTION 


(AV1) Autonomous & Vehicle to Vehicle (V2V) Functions 


AV1 e = Collision Avoidance/Warning/Driver Safety Systems — As discussed in the table in the previous section above, a 

Today number of driver support and safety systems are available through current OEM/bus manufacturers. These 
systems can enhance operational safety and support the reduction of driver fatigue if properly implemented. 
Vehicle turning right warnings (VTRW) may be of particular interest for bus operations. In addition, pedestrian 
proximity and identification systems are widely available on a number of autos that will move into the transit 
industry in the near future. As buses carry a large number of passengers in a variety of configurations, it is 
important to consider the balance of active response (e.g. braking or corrective steering) that may be appropriate 
for individual bus service types. 


AV2 e Prioritizing Transit in Throughput Maximization— Once a broad set of vehicles is implemented with CV capabilities, 
By 2025 it will be possible to implement “intelligent algorithms” that prioritize traffic by type and vehicle operating 
profiles. Early efforts in this area will commence with pilots and specific corridors that will be well suited to 

integration of autonomous and connected vehicles with CV equipped buses. 


AV3 e — Autonomous Operations in Guideways/Transit Lanes — Driver support and guidance systems are already in place 
by 2025- to support bus operations in fixed guideways. By 2025 fully autonomous operations in high capacity transit 
3030 guideways (buses and street operating rail — not just heavy rail) will emerge and become more commonplace. 


e —_Driverless Circulator Shuttles/Services — Initial operational pilot projects for driverless circulator services have 
already been announced and the technology exists to support these functions today. By 2025 the pilot projects 
will move into more widely available options for transit infrastructure and options. 


AV4 e — Fully Autonomous Buses on Regular Routes — The individual technologies for autonomous operations of vehicle 
beyond and buses exist today, but the policy and real-world challenges remain daunting. Ultimately fully autonomous 
3030 operations for buses in regular service, on fixed routes, and mixed-flow traffic will become the norm. 


(Bie] | TREND DESCRIPTION 


(VI) Vehicle to Infrastructure (V2I) Functions 


Vit e Signal Priority Bus/Rail — Many agencies are looking to signal prioritization as an “early win” for piloting CV 
functionality. These projects are somewhat similar to BSP efforts Metro has undertaken in the past but are more 
advanced and utilize CV functionality. Metro is undertaking a study to review the future for BSP that will provide 
more specific discussion of the potential applicability of CV applications to BSP. 


Today 


e Dynamic Ridershare — Transit would be tied into USDOT’s concept for dynamic rideshare CV concepts, which 
would allow transit riders to pass anticipated arrival information to other parties (carpools, shared ride services, 
etc.). 
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(VI) Vehicle to Infrastructure (V21) Functions 


e Integrated Corridor Management (ICM) — As part of a wider ICM concept, transit fleet systems information (such 
as on-board loads and next bus arriving) and related information (parking availability) will be provided to travelers 
along a congested corridor to promote the opportunity and advantages of using transit. This can be particularly 
applicable where transit has the advantage of transit/HOV lanes. 


Vi2 e Managed Reversible Transitways — Reversible transit lanes already exist and are controlled through signage and 
3025- access barriers, but the application of autonomous and connected buses offers a much more intelligent and 
2030 optimized approach to using shorter stretches of reversible lanes able to support both directions of travel 


throughout the day. This becomes more important in an increasingly constrained roadway environment. Utilizing 
fleet systems and CV functions for relative bus positions, current conditions, and historic trends, directions for 
reversible lane use can be automated and integrated directly with access controls/signals. 


e — Dynamic/Variable Use Transit Lanes — Metro already makes widespread use of specially marked transit lanes 
exclusive to buses during particular periods or throughout the day. However, these lanes cannot easily adjust to 
special events, variable traffic patterns, etc. Dynamic lanes will utilize CV functions of both transit vehicles and 
private autos to maintain and control lanes assigned for transit use/priority. 


VI3 e —_ Build Transit Facilities with V2I|/Communications Infrastructure — By this period, the infrastructure elements of CV 
2030 & will be well established and all transit facilities will need to be built to support transit and related V2I functions. 
Beyond 


ta TREND DESCRIPTION 


(SA) Metro Suggested Actions 


SA1 e Connected Bus & Rail Projects with MGR — This is discussed in detail in the recommended on-board architecture 


and projects noted in this Plan. As with fleet systems, the MGR will offer flexible communications for a subset of 
Connected Vehicle functions. OEM safety functions tied directly to active vehicle guidance systems should remain 
independent of the MGR. 


Today 


e New Bus Procurements with OEM Vehicle Safety Systems — Within the next 10 years, buses and rail vehicles 
delivered with a variety of driver support and safety systems will be the norm. As fleet procurements occur over 
a period of time, Metro should consider what OEM vehicle safety and driver support systems would be 
appropriate for subsets of the vehicle fleets. For example, vehicles continuously operating in a freeway/commute 
environment may have different needs than those in continuous local street service. Procurements should allow 
for options for these systems that Metro can act upon at their discretion. 


e Progress with Updated On-Board Bus/Rail Architectures — As with the MGR discussion, the on-board architecture 
recommendations are discussed at length in this Plan. The architecture allows for connected vehicle and 
autonomous functionality in three areas: OEM vehicle systems tied to vehicle guidance and driver support, 
connected vehicle functions using communicated information from other on-board fleet systems to obtain data 
and fulfill functional needs, and specific connected vehicle functions operating on-board the vehicle within the 
IVU/VLU environment. As concepts for Connected Vehicles are rapidly evolving, it is likely that the specific CV 
applications will shift or change over time, but if Metro maintains a non-proprietary and open on-board network 
environment and IVU/VLU, it will greatly assist in supporting future CV applications. 


SA2 


e Plan for Autonomous Bus/Rail Operations — Autonomous operations are nothing new along fixed guideways, but 


Fa the current and emerging set of autonomous vehicle functionality promises to be a game changer in terms of 
oday- 


2025 


what is viable for autonomous operations in guideways, transit lanes with minimal traffic separation, and mixed 
traffic operations. Metro should be planning and considering these technical capabilities in infrastructure 
planning and design efforts. Autonomous operations offer to support higher frequency, precise stop positioning, 
and reduced operating costs over the ensuing two decades. 
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(SA) Metro Suggested Actions 


SA3 e ~=Work with Cities/Partner Agencies to Prioritize Transit Throughput — Metro already supports a variety of Bus Signal 
Priority (BSP) efforts, but CV applications and V2V networks of vehicles offer to enhance opportunities for 
2020- significant advancements in the prioritization of types of traffic by corridor. Metro should be looking for pilot 
Beyond opportunities to promote transit as a logical and continued mode to prioritize along roadway and freeway 
corridors. 
SA4 


e Plan, Design, & Implement Autonomous Bus/Rail Operations — It is likely that by 2030 autonomous bus operations 

2030- will reach into mixed traffic flow situations. Widespread private auto autonomous operations will occur before 
Beyond that time. Metro should be designing and implementing infrastructure, facilities, and operations that take this 
into consideration. It will fundamentally change the methods and approaches Metro currently uses over the next 
twenty years. 
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CONCEPT OF OPERATIONS: TRAIN PULLOUT 


The following scenario illustrates the benefits of the systems to be implemented in the Strategic Plan and highlights the 
changes that will occur from current operations. Current operations that would be phased out by new technology are 


written in this color, while planned operations that would be added with new technology are written in 
this color and underlined. 


TRAIN ASSIGNMENTS 

Bob has been a supervisor for Rail Fleet Services at LA Metro’s Blue Line Division 11 for three years. Each day, he walks the 
rail yard and writes the vehicle numbers and the lanes they are parked in on a piece of paper. Once completed, Bob faxes 
this information to Transportation at Division 11. Bob uses the Rail Yard module of the new Yard Management 
Tool to automatically document the lane location of each train in the yard and confirms the tool has 
logged the vehicle locations. Roman, the Transportation Operations Director, receives the fax from Bob, manually 
uses the Rail Yard module of the new Yard Management Tool which automatically assigns the train to the 
pullout times on the schedule. Roman lists the pullout assignments on a piece of paper and faxes the list to the ROC. The 


train pullout assignments are automatically sent to Hastus and ATMS II by the Yard Management 
Tool. 


OPERATOR CHECK IN 

Dan has been a LA Metro train operator for ten years and arrives at the Division 11 Blue Line yard to begin his work shift. 
Dan checks in using his badge to log into the Hastus Daily System on a workstation at the Yard Control Window. The Hastus 
System provides him with Operation Clearance Notices (OPS CLR), and prints out the pink letters. The Yard controller tells 
the operator where the operator’s train is and writes down the operator assignments on a change sheet. Dan carries a 
printout of the train schedules and pink letters with him as he walks to the train. The Yard Controller checks to see if there 
are any notifications such as “see supervisor” or “complete transit safe form” for Dan that have been sent from 
ATMS Il. The Yard Management Tool receives Dan’s log in information from the Hastus System and 
automatically assigns Dan with a train ID and automatically sends the train ID and its location 
information to Hastus. The Hastus System provides Dan with the train ID and location of the train. 


Dan can access the train schedules and pink letters via the MDT for ATMS II. The operator train 
assignments are automatically sent to ATMS II by the Yard Management Tool. 


PRE TRIP INSPECTION 
Dan performs a pre-trip inspection of his assigned train and notes the results of the inspection on a Vehicle Condition Card. 


Dan logs into the MDT for ATMS II and enters the results of the pre-trip inspection. Once the pre-trip 
information has been entered, a pre-trip report that satisfies CHP is sent to the ATMS II backend via 


the Aruba WLAN system in a data message. 


TRAIN DEFECT REPORTING 

Dan discovers there is a defect with the train during the pre-trip inspection and uses the Blue Line Yard Channel of the voice 
radio system to call and inform Diana, the Blue Line Yard Controller, of the defect. ATMS || receives the pre-trip 
information from Dan’s train and since a defect was noted, ATMS II sends a maintenance work order 
request to M3. Diana contacts Maintenance via telephone or via the Maintenance channel of the voice radio system to 
have Jeff, a vehicle technician repair the train. Jeff attempts to repair the defect but is unsuccessful and using the 
Maintenance channel of the voice radio system, notifies Diana. Jeff tags the train as defective. Jeff creates a work 
order in M3 for Dan’s train and notes the defect using the laptop that is mounted in his maintenance 
vehicle. 
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TRAIN REPLACEMENT 

Diana, using the Yard Management Tool, manually assigns a new train to Dan. Diana uses the new Yard 
Management Tool and submits a request for a new train. The new Yard Management Tool 
automatically identifies, locates, and assigns a new train to Dan. 


PRE TRIP INSPECTION 

Dan makes his way to his new train and performs a pre-trip inspection of his newly assigned train and notes the results of 
the inspection on a Vehicle Condition Card. The train passes the pre-trip inspection. Dan logs into the MDT for ATMS 
ll and enters the results of the pre-trip inspection into the pre-trip inspection page of the MDT. 
Once the pre-trip information has been entered, a pre-trip report that satisfies CHP is sent to the 
ATMS II backend via the Aruba WLAN system. The onboard ATMS II system automatically commands 
the train’s destination signs to display the correct destination and commands the Onboard Passenger 
Information system to display the correct information based on Dan’s log-in information. 


LATE TRAIN PULLOUT 

Since Dan has exceeded his 25 minute window for his pre-trip, he will not pullout at his normally scheduled time. Diana uses 
the Blue Mainline channel of the voice radio system to notify Bill, the Blue Line Mainline Controller who is located at the 
ROC of the late pullout. Bill uses his ATMS Il workstation to review the operator assignments and train 
pullout assignments. To compensate for Dan’s late pullout, Bill uses his ATMS Il workstation and adjusts the 
Blue Line schedule by bumping the line or using a gap train at the terminal. ATMS || sends the adjustments to 
Hastus and to the rail prediction engine. 


There were no defects discovered and so Dan calls Diana via the Blue Line Yard channel of the voice radio system to request 
authorization to move the train to the yard limits. Diana grants authorization and when Dan reaches the yard limits, Dan 
uses the Blue Mainline channel of the voice radio system to request authorization to go into service from Bill, the Blue Line 
Mainline Controller who is located at the ROC. Bill verbally provides authorization. Bill verbally provides all new updates to 
the OPS CLR and Dan repeats them verbatim. All notices, entered into ATMS II by Bill and other Mainline 
Controllers are also sent by ATMS Il to the MDT via the Aruba WLAN system and Dan reads each 
notice. Using the MDT, Dan sends an acknowledgement for each notice to Bill via the Aruba WLAN 
system. Bill looks at his ATMS || workstation display and notes that Dan has acknowledged all notices 
and therefore does not verbalize them to Dan. Bill manually logs the pullout of Dan’s train in a Train summary 
report. The new Yard Management tool tracks the movements of Dan’s train and automatically logs 
and sends the yard pullout data to ATMS Il. 


VEHICLE LOCATION AND STATUS TRACKING 

The SCADA system tracks the location of Dan’s train and all other trains on the Blue as they proceed on their trips and 
displays their locations on the SCADA workstation displays. The NextBus system receives the train location information from 
SCADA and Hastus, calculates the train’s arrival at the Blue Line stops, and provides this information to Trip Master. The 
Onboard ATMS II system collects vehicle location data from the GPS receiver and sends position 
updates every 30 seconds to the ATMS || backend via the cellular data network. ATMS II collects 
vehicle location data provided by beacons installed at key locations on the tracks and merges this 
information with the GPS data from the train, and the train tracking location information from 
SCADA to calculate the location of Dan’s train and display it on a map display on the ATMS Il 
workstation for Bill and the other controllers that are managing the Blue Line. The rail prediction 
engine uses the train locations provided by ATMS II and information from SCADA and Hastus to 
predict the train’s arrival at the Blue Line stops and provides this information to the Enhanced 
Multi-modal Real-time Aggregation System, and Metro’s GTFS-realtime Feed which provides traveler 
information to Metro’s passengers via Nextrip, RIITS, and Metro’s smartphone app and website. 
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PASSENGER INFORMATION 

Sheila is a long time Metro passenger who is commuting to work on the Blue Line. She uses her smartphone to access 
Metro’s smartphone app or website, which provides her with the predicted arrival time of the next train. She boards Dan’s 
train at the Willow station. While onboard, Sheila receives passenger information, general service announcements, and 
infotainment from the LCD monitors and the PA system. When the train is approaching a station, Dan presses a button 
to trigger the next stop announcement on the PA system and LCD monitors. The Onboard ATMS II system provides 
Sheila with real-time passenger information via the LCD displays and PA system. The Onboard ATMS 
Il system calculates the position of Dan’s train and automatically announces the upcoming stations 
on the onboard LCD passenger information display and on the PA system. The LCD display alternates 
between providing a list of the upcoming stations and general service announcements and possibly 
location-based advertising. Sheila can also access the internet using her smartphone using the 
passenger Wi-Fi system provided by Metro. 


DATA MESSAGING 

Dan receives voice announcements from the Bill and other Blue Line controllers from the Blue Line using the Blue Line 
mainline channel of the voice radio system and repeats them verbatim back to the controllers. Dan also receives text 
message notices from Bill and other Blue Line controllers via the cellular data network on his MDT. 


Dan reads the notices and sends acknowledgements using the MDT to Bill and the other Blue Line 
controllers via the cellular data network. 


END OF LINE LOGOFF 

When Dan’s train reaches the end of the line, Dan logs off the MDT and departs from the train and takes his 
break. Frank, a fallback operator boards the train, logs onto the MDT and receives any updates to OPS CLR 
on the MDT and sends an acknowledgement to the Blue Line controllers via the cellular data 
network. 
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CONCEPT OF OPERATIONS: BUS ROLLOUT 


The following scenario illustrates the benefits of the systems to be implemented in the Strategic Plan and highlights the 
changes that will occur from current operations. Current operations that would be phased out by new technology are 
written like this, while planned operations that would be added with new technology are written in this 
color and underlined. 


BUS ASSIGNMENTS 

Bob has been the lead ERS at LA Metro’s Division 10 for three years. Each day, after buses return from service they are 
cleaned, refueled, and parked. Bob walks the yard and notes the parking location and type of each bus on a piece of paper 
called a Yard Sheet. Bob returns to his office where he uses his desktop PC to log into HASTUS Daily to assign buses to work 
assignments based on the rollout position of the bus. Bus operators that are working each assignment are also assigned to 
the bus and this information is stored in HASTUS Daily. Bob uses the Bus Yard module of the new Yard 
Management Tool that automatically locates the buses in the yard, and assigns operators and work 
assignments to each bus based on operator and work assignment data that is automatically imported 
from HASTUS Daily. The bus assignments for the operators are automatically sent from the Yard 
Management Tool to HASTUS Daily. 


OPERATOR CHECK IN 

Danielle has been an operator for Metro for seven years. She arrives at the Division 10 yard and checks in with Carlos, the 
Window TOS. As the Window TOS, Carlos is responsible for checking in the operators. He greets Danielle and Danielle uses 
her badge to authenticate herself on the workstation located at the check-in window into the HASTUS Daily system and 
receives her bus assignment and location, work assignment, and paddle printout. Carlos checks to see if there are any 
notifications such as “see supervisor” or “complete transit safe form” for Danielle that have been sent to him from 
ATMS Il. Danielle can access the paddle and pink letters via the MDT for ATMS ll. 


PRE TRIP INSPECTION 

Danielle knows she has thirteen minutes to find her assigned bus, turn it on, power up the ATMS MDT and the farebox, and 
log onto the farebox or ATMS MDT with her badge. She performs a pre-trip inspection and notes the results on a 
Maintenance 9 card and notices that there is a brake issue. She enters the pre-trip inspection results on the 
pre-trip inspection page of the MDT. Once completed, the pre-trip inspection report is sent to the 
ATMS || backend via the upgraded Aruba WLAN in the yard. 


BUS DEFECT REPORTING 

ATMS II receives the pre-trip information from Danielle’s bus and since a defect was noted, ATMS 
sends a maintenance work order request to M3. Since the report indicates there is a mechanical 
defect, a service message is automatically routed to the ATMS || workstation in maintenance area. 
Jeff, the Yard TOS, receives notification via WLAN of the defect on Danielle’s bus on his tablet or 
laptop while he is in his vehicle or in his office. Danielle finds Walter, a mechanic at Danielle’s division and 
notifies him of the bus defect but Walter says he is backed up and that it will take him more than hour to get to Danielle’s 
bus to fix the defect. Walter creates a work order in M3 for Danielle’s bus and notes the defect using the 
laptop that is mounted in his maintenance truck. 


BUS REPLACEMENT 

Danielle finds Jeff, the Yard TOS on duty. Jeff manually selects another bus for Danielle to use Jeff uses the new Yard 
Management Tool to automatically identifies, locates, and assigns a new bus to Danielle. Using his 
tablet or laptop with a wireless connection to M3, Jeff makes a note about the defective bus in M3 and enters 


Danielle’s new bus assignment into HASTUS Daily the Bus Yard Tool which sends Danielle’s new bus 
assignment to HASTUS Daily. 
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PRE TRIP INSPECTION 

Danielle makes her way to her new bus, which passes the pre-trip inspection perfectly. She fills out the Maintenance 9 card. 
Danielle logs into the MDT and enters the results of the pre-trip inspection into the pre-trip inspection 
page of the MDT. She places the Maintenance 9 card in the bus windshield for review at the CHP’s discretion. Once 
the pre-trip information has been entered, a pre-trip report that satisfies CHP is sent to the ATMS ll 
backend via the Arruba WLAN system in a data message. The onboard ATMS Il system automatically commands 
the bus’s destination signs to display the correct line and destination and commands the Onboard Passenger Information 
system to display the correct information based on Danielle’s log-in information. 


YARD PULLOUT 

As Danielle pulls out of the yard, Jeff, the Yard TOS logs her pullout on a piece of paper as the bus leaves the Division 10 
yard the Bus Yard tool automatically logs the departure of Danielle’s bus and stores the information 
in the new ATMS database. 


VEHICLE LOCATION AND STATUS TRACKING 

Danielle’s bus receives GPS coordinates from the GPS satellites and transmits its location information to the ATMS backend 
via the ATMS data radio system every 3 minutes ATMS I| backend via Metro’s fleet cellular data network every 
30 seconds. When Antonio sees the status of Danielle’s bus on the ATMS |! displays at his workstation, he can see the 
location of her bus, real-time passenger count, and its Deadhead status. ATMS || provides the real-time location of 
Danielle’s bus to NextBus, which provides real-time location information and predictions and predictions for 
Danielle’s bus to the Enhanced Multi-modal Real-time Aggregation System, and Metro’s GTFS- 
realtime feed to Nextrip, RIITS, and Metro’s smartphone app and website. When Danielle’s bus reaches the first 
timepoint, the status of Danielle’s bus changes on to, “Service.” 


FARE COLLECTION 

Sara is a long time Metro passenger who is commuting to work on via the Metro bus system. She uses her smartphone to 
access Metro’s app that provides her with the predicted arrival time of the next three bus arrival times at her stop. While 
waiting for the bus, Sara uses the Metro website or app to add value to her TAP card. Once the value has been added, the 
UFS system sends an update to all of the fareboxes via the yard WLAN system when the buses return to the bus yard 
immediately via Metro’s fleet cellular data network. Danielle’s bus arrives and Sara touches the farebox’s 
validator with her TAP card as she boards the bus. Danielle uses the farebox’s operator control unit ATMS || MDT to 
perform farebox functions and the operator control unit ATMS || MDT displays the remaining value left on Sara’s TAP 
card. 


PASSENGER INFORMATION 

While onboard, Sara receives passenger information and infotainment from the PA system and LED signs LCD 
monitors. The LED signs display next stop information, stop requested notifications, and general service announcements. 
The LCD display alternates between providing a list of the upcoming stops, stop requested 
notifications, general service announcements and possibly location based advertising. Sara can also 
access the internet using her smartphone using the passenger Wi-Fi system provided by Metro. 
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CONCEPT OF OPERATIONS: TRAIN EMERGENCY 


The following scenario illustrates the benefits of the systems to be implemented in the Strategic Plan and highlights the 
changes that will occur from current operations. Current operations that would be phased out by new technology are 
written like this, while planned operations that would be added with new technology are written in this 
color and underlined. 


NORMAL OPERATION 

David has been an LA Metro train operator for four years. Most of his operator experience has been running trains on the 
Gold line, but he has recently been transferred to the newly expanded Expo Line, which he is operating when today’s 
incident occurs. David leaves the downtown Santa Monica station and heads eastbound on tracks that run along Colorado 
Avenue in Santa Monica. The SCADA system provides approximate location information for David’s train by indicating which 
train track the train is on. David’s train receives GPS coordinates from the GPS satellites and transmits its 
location and passenger count to the ATMS II backend via the Metro fleet cellular data network every 


30 seconds. ATMS Il tracks the location of David’s train by merging GPS data with SCADA data and 
displays its location and passenger count on a street map. 


COLLISION AND EMERGENCY NOTIFICATION 

Rodrigo, a roofing contractor, is late for an appointment and he is driving south on 11th street. At the Colorado/11th Street 
at-grade crossing, Rodrigo runs through a red light, hoping to cross Colorado before the oncoming train. David sees 
Rodrigo’s truck crossing in front of him and applies the LRV’s brakes but it is not enough to avoid a collision. The front left 
corner of his train smashes into the right rear corner of Rodrigo’s truck. David brings the train to a full stop and using the 
Expo Line channel of the Icom voice radio system calls the mainline controller for the Expo line at the ROC to respond to a 
T73 (train vs. auto). David presses an emergency button on the ATMS || MDT to tag the video data before 
and after the collision so the data can be more easily retrieved and will not be overwritten. During 
the emergency event, the onboard ATMS Il system streams the onboard video images to the cloud via 
the Metro fleet cellular data network where it is temporarily cached so the video can be viewed by 
Metro staff. The collision triggers an event notification on the SmartDrive system, which uploads data regarding the 
collision via the SmartDrive cellular link the Metro fleet cellular data network to SmartDrive for storage and 
analysis. 

Angela is the mainline controller for the Expo line and answers David’s the radio call. David provides Angela with his 
location, direction and severity of the damage. Angela confirms David’s location by looking at his train 
location as indicated on her ATMS II map display. David describes what happened. Angela activates the 


video streaming function to view the current situation onboard the train. She is able to view images 
from each camera. 


Since David’s train is stopped due to the collision, Angela sees on her SCADA workstation that the train location on remains 
on one of the tracks but it does not indicate that the train is stationary. Angela can see from the street map on her 
ATMS || workstation that David’s train is stationary. ATMS II indicates the train has stopped and 
adjusts the predicted arrival time for David’s train. Using her ATMS || workstation, Angela places 
David’s train in “inactive status,” causing ATMS II to remove all predictions for the train and to 
forward this information to the multi modal real-time aggregation system, which then provides the 
information to Nextrip. 


FIELD SUPERVISOR SUPPORT 

After using her ATMS II map display to determine who is closest to the incident, Angela issues a call on 

the Expo line channel of the Icom voice radio system for any field supervisor for Mark, a field supervisor, who she 
can see on the map is already nearby, to head to the scene. Using her ATMS II workstation, Angela types 
a message with instructions to manage the incident and sends it to Mark’s ATMS portable laptop or 
tablet via Metro’s fleet cellular data network. Mark receives the message on his ATMS portable 
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laptop or tablet and sends an acknowledgement response via Metro’s fleet cellular data network. 
Angela sees the acknowledgement response on her ATMS II workstation. Angela also calls 911 using her 
telephone handset and reports the accident to the police. 

Mark arrives at the scene and sets up a command outpost as the on-scene coordinator. Mark provides updates to the ROC 
using his lcom voice radio. Mark also uses his cell phone to coordinate with other agencies as needed. Emergency medical 
services personnel and Santa Monica police quickly arrive on the scene to attend to the truck driver and the train 
passengers. While EMS personnel talk to passengers, and the police talk to Rodrigo and David, Mark examines the train 
thoroughly. Mark uses the Expo Line channel of the Icom voice radio system to call Tim, the Expo Line yard controller to 
create a shell for an accident report in Transit Safe. Mark takes pictures and writes notes to document the incident. When 
Mark has finished his work at the scene of the accident, he must drive to the rail yard to download the pictures he took and 
file a 172 report on a desktop PC running the Transit Safe software. Angela also files an accident report, but she files hers in 
M3. Angela creates an incident form for the accident in ATMS II and ATMS II automatically identifies 
potential spelling errors. Mark takes pictures and logs notes using his ATMS portable laptop or 
tablet. While on scene, Mark creates a shell for an accident report in Transit Safe and uploads his 
172 report using the Metro fleet cellular data network to connect to Transit Safe. Mark also submits 
updates to the ATMS incident form created by Angela using his ATMS portable laptop or tablet. 

Mark uses his portable to advise Angela that the media has arrived on scene using Expo line channel of the Icom voice radio 
system. Angela calls Media Relations to advise them of the situation. When approached by media folks, Mark refers them to 
contact Media Relations for information. 


BUS BRIDGE 

Mark realizes that a bus bridge will be needed while the incident is resolved and informs Angela. Angela calls the BOC to 
request a bus bridge until the incident is closed and creates a bus bridge incident in ATMS lI. The bus bridge 
process described in the BUS BRIDGE SCENARIO occurs. 


RESUMPTION OF SERVICE 

Mark issues Courtesy Cards to the passengers and collects the cards that are completed at the scene. Mark uploads images 
of the completed courtesy cards when he returns to the rail yard while on scene using the ATMS portable laptop 
or tablet. Mark remains on scene as the coordinator until resolution of the incident. If the incident takes more than 12 
hours to be concluded, another field supervisor will be sent to the scene to relieve Mark. 

Since the damage to the train appears minor and is mostly cosmetic, Mark uses his portable to advise Angela that David’s 
train should be placed back in service now that the police have concluded their investigation. Using her ATMS II 
workstation, Angela ends the bus bridge event and places David’s train back in “active status,” 
causing ATMS II to resume providing predictions for the train and to forward this information to the 
multi modal real-time aggregation system, which then provides the information to Nextrip. ATMS Il 
automatically sends an alert removal notification of the bus bridge to the Enhanced Multi-modal 
Real-time Alerts System which removes the alert from the appropriate systems including electronic 
rail station and bus stop signs. 


TRANSIT SAFE REPORT 

Angela calls Manny, the window dispatcher for the Expo Line Division 14 and tells him ATMS Il automatically sends an 
alert to Manny, the window dispatcher for Division 14 and to Hastus that David needs to complete a Trans 
30 report when he returns to the division. 

Video from the onboard video security system is reviewed when the train returns to the rail yard and the hard drive from 
the DVR is removed and downloaded. SmartDrive data from the collision is also reviewed. Additional courtesy cards that 
have been mailed in are sent to the Expo Division and where they are reviewed and entered into the Transit Safe report. 
Manny tells David to complete a Trans 30 report on a desktop PC running the Transit Safe software when he returns to 
Division 14. David also receives an alert to complete the Trans 30 report when he checks in at a Hastus 
workstation. 
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CONCEPT OF OPERATIONS: BUS EMERGENCY SAS 


The following scenario illustrates the benefits of the systems to be implemented in the Strategic Plan and highlights the 
changes that will occur from current operation. Current operations that would be phased out by new technology are 
written like this, while planned operations that would be added with new technology are written in this 
color and underlined. 


NORMAL OPERATION 

Don has been an LA Metro bus operator for ten years and is now based at Division 13. Don is driving an articulated bus for 
the 720 line eastbound on Wilshire Boulevard in Santa Monica towards downtown Los Angeles. Don’s bus receives GPS 
coordinates from the GPS satellites and transmits its location and passenger count to the ATMS backend via the ATMS 
data radio system every 3 minutes to the ATMS II backend via the Metro fleet cellular data network every 
30 seconds. ATMS tracks the location of Don’s bus and displays its location and passenger count on an AVL map. Don’s 
vehicle location is automatically sent from ATMS to the TDB and to NextBus the multi modal real-time aggregation 
system which provides the information to Nextrip. 


FALSE ALARM 

As the bus crosses Lincoln Boulevard, Don’s bus inadvertently activates a silent alarm (SAS) when a car merges into Don’s 
lane and Don has to brake suddenly. The SAS message is sent by the onboard ATMS II system to the BOC via the ATMS data 
radio system via Metro’s fleet cellular data network. Don can see a subtle indicator from the ATMS MDT that the 
SAS alarm has been sent to the BOC. The SAS activation also causes the onboard video security system to record at a higher 
frame rate and to tag the video data; allowing it to be more easily retrieved and preventing it from being overwritten. All of 
the controllers in the BOC see the SAS on their ATMS displays and hear an audio alarm as well. A window pops up on the 
map display that shows the location of Don’s bus. While an SAS is active, Don’s bus sends location updates to the BOC every 
15 seconds via the ATMS data radio system via Metro’s fleet cellular data network. Ann, the controller who is 
assigned to the 720 line, opens an incident for the SAS at her workstation, which causes the audio alarms on all of the other 
controllers’ workstations to stop. When Ann opens the incident form, the onboard ATMS system for Don’s bus 
automatically begins to broadcast audio from the covert microphone via the ATMS voice radio system via the VoIP 
system and streams the onboard video to the cloud via Metro’s fleet cellular data network. Don seesa 
subtle indicator provided by ATMS MDT that a covert microphone and streaming video have has been activated. Paul 
is the Sheriff dispatcher who is on duty at the BOC. He sees the SAS on his ATMS workstation and hears the audio from the 
covert microphone and sees streaming video from the bus. After listening to the covert mic for a few minutes, Paul 
does not hear anything that would indicate there is an emergency situation. Paul and Ann confer and due to the 
uncertainty, Paul has to dispatch a Sheriff to the bus using his Sheriff dispatch console. The dispatched Sheriff reaches the 
bus and determines there is a false alarm. Paul and Ann are able to selectively view the video from each of 
the cameras and listen to the audio from the selected camera. They determine there is a false alarm. 
Ann overrides the SAS. The ATMS MDT reverts to its normal display and the bus location updating to the BOC returns to the 
standard rate of once every 3 minutes 30 seconds. Ann sends a pickup message to the ATMS MDT on Don’s bus via the 
ATMS data radio system via Metro’s fleet cellular data network. Don sees the message and pushes the Press to 
Talk on the handset and begins to talk to Ann via the via the ATMS voice radio system via the VoIP system. Ann confirms 
with Don that the SAS was a false alarm. After Don confirms the false SAS, Ann asks Don to pull over and see if the headsign 
is displaying “Call Police.” Don pulls over and sees that the headsign is displaying the correct route and destination. Don 
relays this to Ann and she instructs Don to continue his service. 


SAS ALARM 


As Don’s bus continues eastward on Wilshire Blvd, a passenger boards at the Westwood stop and begins to argue with Don 
because he doesn’t have enough money on his TAP card or cash to pay for the fare. The passenger states that additional 
funds were added to his TAP card so there is a mistake with his TAP account. Since the fareboxes are connected to 
the UFS backend via Metro’s fleet data network to get real-time updates to TAP accounts, Don tells 


shows the TAP balance on the passenger’s card via the ATMS II MDT display that also serves as the 
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control head for the farebox. Don asks the passenger to step off the bus but the passenger refuses and begins to 
verbally assault Don. Don presses the SAS button. The SAS message is sent by the onboard ATMS system to the BOC via the 
ATMS data radio system via Metro’s fleet cellular data network. Don can see a subtle indicator from the ATMS 
MDT that the SAS alarm has been sent to the BOC. The SAS activation also causes the onboard video security system to 
record at a higher frame rate and to tag the video data; allowing it to be more easily retrieved and preventing it from being 
overwritten. All of the controllers in the BOC see the SAS on their ATMS displays and hear an audio alarm. A window pops 
up on the map display that shows the location of Don’s bus. While an SAS is active, Don’s bus sends location updates to the 
BOC every 15 seconds via the ATMS data radio system via Metro’s fleet cellular data network. Ann sees the new 
SAS from Don’s bus and opens an incident form for the new SAS at her workstation, which causes the audio alarms on the 
all of the other controllers’ workstations to stop. When Ann opens the ATMS incident form, the onboard ATMS system for 
Don’s bus automatically begins to broadcast audio from the covert microphone via the ATMS voice radio system via the 
VoIP system and streams the onboard video to the cloud via Metro’s fleet cellular data network. Don 
sees a subtle indicator provided by ATMS MDT that a covert microphone and streaming video have has been 
activated. Paul is the Sheriff dispatcher who is on duty at the BOC. He sees the SAS on his ATMS workstation and hears the 
audio from the covert microphone and sees streaming video from the bus. Paul and Ann are able to 
selectively view the video from each of the cameras and listen to the audio from the selected 
camera. Paul and Ann determine that this is a true SAS and Paul dispatches a Sheriff to Don’s bus. Ann documents the 
details of the SAS in the ATMS incident form and ATMS II automatically identifies potential spelling errors. 
Ann uses her ATMS workstation to create an All Call broadcast to all road supervisors on the Supervisor talk group of the 
ATMS voice radio system_VoIP_ system. The All Call broadcast message causes the portables for the Road Supervisors to 
beep three times, which alerts the supervisors to write down the information from the Code 1 call. Ann sends the 
information in a text message to the laptop portable laptop or tablet in the Road Supervisor vehicles via the cellular 
data network. Tom and Al, the first two road supervisors to respond, head to Don’s bus. They use their laptop portable 
laptop or tablet to acknowledge Ann’s message and track the location of Don’s bus. The road supervisors follow Don’s 
bus and observe what is occurring on the bus, but do not attempt to board the bus, as they wait for the Sheriff to arrive. 
The Sheriff reaches Don’s bus and pulls in front of it, causing the bus to stop. The sheriff uses a bull horn and orders the 
unruly passenger to leave the bus. The unruly passenger refuses and states he is armed. Don opens the front and rear doors 
and all of the passengers and Don quickly leave the bus leaving the unruly passenger as the only one onboard. A tense 
standoff ensues. Tom uses his portable to call Ann via the ATMS voice radio system via the VoIP system and advise her 
of the situation. Ann calls 911 for a police support. Ann and the Paul continue to listen to the covert audio listen to the 
covert audio and watch the streaming video from the bus on their ATMS workstations in the BOC and share this 
information with law enforcement. 


As the standoff continues, the police close off Wilshire Boulevard in the vicinity of the bus. Tom uses his portable to advise 
Ann that the media has arrived on scene via the ATMS voice radio system via the VoIP system. Ann calls Media 
Relations to advise them of the situation. When approached by media folks, Tom refers them to contact Media Relations for 
information. 


DETOUR 

Tom uses his portable to advise Ann of the street closure via the ATMS voice radio system via the VoIP system. Ann 
uses her ATMS workstation to create a detour around the road closure for the 720 line and sends a detour message to all 
operators that are currently operating or are scheduled to operate on the 720 line via the ATMS data radio system via 
Metro’s fleet cellular data network. Ann uses an Everbridge workstation to type an alert message regarding the 
detour and notifies social media of the detour ATMS II automatically sends an alert notification to the 
Enhanced Multi-modal Real-time Alerts System which disseminates the alert to the appropriate systems 
including electronic bus stop signs. Jack is an operator on the 720 line and sees the detour message on his MDT. 
The MDT displays a map of the detour route. Ann uses her ATMS II workstation to send a detour 
notification message that is displayed on the LCD monitors on all buses via Metro’s fleet cellular 
data network. Ann uses her ATMS II workstation to make a voice announcement of the detour on the 
PA systems for all 720 line buses via the VoIP system. 
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ATMS tracks the location of Jack’s bus and other buses on the 720. Since a detour has been established, the buses do not 
indicate an off-route status while on the detour. ATMS || adjusts the arrival predictions based on the 
additional distance the buses must travel due to the detour and removes arrival predictions for stops 
that are bypassed as a result of the detour. ATMS II removes the display of time of arrival 
predictions on electronic signs at the bus stops that are bypassed. 

Since Don’s bus is stopped due to the emergency situation, ATIMS first changes the bus’ status to late and Nextrip adjusts 
the predicted arrival time for Don’s bus. ATMS then changes the bus’ status to a no show when the bus fails to make two 
time point encounters and forwards the bus’ location information to NextBus which provides the information to Nextrip. 
Using her ATMS || workstation, Ann places Don’s bus in “inactive status,” causing ATMS || to remove 
all predictions for the bus and to forward this information to the multi modal real-time aggregation 
system, which then provides the information to Nextrip. 


RESOLUTION OF EMERGENCY 

The unruly passenger finally leaves the bus and is taken into custody without further incident. Tom takes notes for a report 
to be filed in Transit Safe for this incident when he returns to his division uses his portable laptop or tablet to 
complete the Transit Safe report and submits it via Metro’s fleet cellular data network. Tom uses his 
portable to advise Ann of the emergency resolution via the ATMS voice radio system via the VoIP system. Ann uses her 
ATMS workstation and overrides the SAS and places Don’s bus back in “active status.” The ATMS MDT reverts to 
its normal display and the bus location updating to the BOC returns to the standard rate of once every 3 minutes 30 
seconds. 


REMOVAL OF DETOUR 

Now that the situation has been resolved, the police re-open Wilshire Blvd. Ann uses her ATMS workstation to cancel the 
detour she had created previously and sends a cancel detour message to all operators that are currently operating or are 
scheduled to operate on the 720 line via the ATMS data radio system via Metro’s fleet cellular data network. Ann 
uses one of the Everbridge workstations to cancel the alert message regarding the detour and notifies social media of the 
detour cancellation ATMS Il automatically sends an alert removal notification to the Enhanced Multi- 
modal Real-time Alerts System which removes the alert from the appropriate systems including 
electronic bus stop signs. Jack is an operator on the 720 line and sees the detour cancellation message on his MDT. 
Jack’s MDT no longer displays a map of the detour route. Ann uses her ATMS workstation to remove 
the detour notification message that are being displayed on the LCD monitors on all buses via 
Metro’s fleet cellular data network. Ann uses her ATMS workstation to makes a voice announcement 
that the detour has been canceled on the PA systems for all 720 line buses via the VoIP system. 
ATMS II re-adjusts the arrival predictions so additional time is no longer added for the extra distance 
buses were traveling on the detour and reinstates arrival predictions for stops that had been 
bypassed as a result of the detour. ATMS II reinstates the display of time of arrival predictions on 
electronic signs at the bus stops that had been bypassed. 


RESUMPTION OF SERVICE 

Don returns to his bus. Ann sends a pickup message to the ATMS MDT on Don’s bus via the ATMS data radio system via 
Metro’s fleet cellular data network. Don sees the message and pushes the Press-to-Talk on the handset and begins 
to talk to Ann via the ATMS voice radio system VoIP system. Ann asks Don to check the headsign display. Don checks the 
headsign and tells her the display says “Call Police”. Ann tells Don to have one of the road supervisors reset the headsign by 
shutting off the bus’ battery by (using maintenance codes) on the ATMS MDT. Once the Tom and Al have 
concluded their investigations and the headsign has been reset, Don continues his work assignment. ATMS resumes 
tracking the location of Don’s bus and displays its location and passenger count on an AVL map. Don’s vehicle location is 
automatically sent from ATMS to the TDB and to NextBus the multi modal real-time aggregation system which 
provides the information to Nextrip. 


TRANSIT SAFE REPORT 
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Ann calls the Mark, the window dispatcher for Division 13 and tells him ATMS Il automatically sends an alert to 
the Mark, the window dispatcher for Division 13 and to Hastus that Don needs to file a report in Transit Safe 
when he returns to the division. 
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CONCEPT OF OPERATIONS: BUS BRIDGE 


The following scenario illustrates the benefits of the systems to be implemented in the Strategic Plan and highlights the 
changes that will occur from current operation. Current operations that would be phased out by new technology are 
written like this, while planned operations that would be added with new technology are written in this 
color and underlined. 


As a result of electrical issues at the Pershing Square Metro station, there is a complete shutdown of the station, blocking 
the Red and Purple Lines. Angela, the Red and Purple Line controller receives alarm notifications from her SCADA 
workstations regarding breakdowns at the Pershing Square Station. Angela uses her SCADA workstation to shut down all 
tracks to the station. Consequently, a bus bridge must be established. 


CREATION AND NOTIFICATION OF BUS BRIDGE- RAIL 
SCADA updates rail run info via the transit database (TDB), which in turn causes Nextrip to revise its rail predictions. 


Updated prediction information is fed from Nextrip to the website, API, Go511, smartphone 
applications, and social media such as Twitter and Facebook. 


Angela uses the rail voice radio system to call all operators on the affected rail lines to announce the bus bridge. Using 
her ATMS II ROC controller workstation, Angela creates a bus bridge incident. She lists affected 
lines & stations, and retrieves the bridge route stored in the ATMS II database. ATMS Il 
automatically sends a bus bridge information message using the cellular data network to all affected 
trains and is displayed on each of the MDTs on the affected trains. 


Barney, a rail operator on Red Line train and all other operators on the Red Line and Purple, receives Angela’s call and uses 
the rail voice radio system to repeat verbatim Angela’s announcement uses the onboard MDT to send an 
acknowledgement to Angela via the Metro fleet cellular data network. Using her ATMS II 
workstation, Angela verifies all affected operators have acknowledged her bus bridge announcement. 


Barney then uses his train’s PA system to notify his passengers of the curtailed service and provides them information about 
the bus bridge. ATMS || automatically sends a bus bridge information message using the cellular data 
network to be display on the onboard LCD monitors for all affected trains and is displayed on each of 
the MDTs on the affected trains. 


Angela uses an Everbridge workstation to type an alert message regarding the bus bridge and notifies social media of the 
bus bridge. ATMS Il automatically sends an alert notification of the bus bridge to the Enhanced Multi- 
modal Real-time Alerts System which automatically sends alert notifications to be displayed on the 
appropriate systems including electronic rail station and bus stop signs. 


CREATION AND NOTIFICATION OF BUS BRIDGE- BUS 


Angela calls contacts Antonio, a controller at the BOC and requests a bus bridge. Antonio, using his ATMS || 
workstation sees the creation of a bus bridge. Antonio notifies George, the fleet manager, to assign buses for 
the bus bridge. George assigns buses and documents the buses pulled using his ATMS II workstation enters the 
buses pulled for bus bridge incident. After George has assigned the buses, he uses the ATMS voice radio system 
VoIP system, to call the operators of the buses to notify them of their bus bridge assignment. George finds a hardcopy of 
directions for a the bus bridge routes established for this particular bus bridge and types the bus bridge information in a 
message to be sent to the operators via the ATMS data radio system. George pulls up the bus bridge information 
stored in ATMS II database and forwards this instructions to the operators via the Metro fleet 
cellular data network. 
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Marjorie, a bus operator with Metro for fifteen years, receives a Bus Bridge message on her MDT listing the pickup location 
and route for the bus bridge. Her MDT displays a map of the bus bridge route. Marjorie sends an 
ACKNOWLEDGE message on her MDT screen to indicate receipt of the information. The message is sent to George via the 
ATMS data radio system via the Metro fleet cellular data network. Antonio and George, sees the 
acknowledgement by Marjorie and the other operators on their ATMS workstations. Marjorie does not change her 
headsign display Marjorie logs out of her current assignment and logs back in with a work assignment 
for this particular bus bridge with changes her headsign display and begins driving to the 7 and Metro 
Center station to pick up passengers. 


MANAGEMENT OF THE BUS BRIDGE 


Antonio, the Lead Controller for the bus bridge uses his ATMS workstation to transmit the bus bridge route information via 
the ATMS data radio system via the Metro fleet cellular data network to all bus road supervisors assigned to the 
bus bridge. Dwight, a twenty-year veteran Metro Bus Supervisor, receives his bus bridge assignment on his Road supervisor 
mobile data computer Road Supervisor tablet or portable laptop. Dwight has been assigned to managing the bus 
bridge for rail passengers exiting the 7" Street/ Metro Center station. Dwight sends an acknowledgement of 
receipt of the bus bridge message using his Road supervisor mobile data computer Road Supervisor tablet 
or portable laptop. Dwight proceeds to drive to the 7" Street/ Metro Center station. 


Angela, the ROC Controller, uses her ATMS II controller console to send the bus bridge assignment information via the 
cellular data network to all rail road supervisors assigned to the bus bridge. Robert, a rail field supervisor, receives a radio 
call from the ROC receives a notification on his supervisor tablet. He has been assigned to the 7* Street / Metro 
station to manage the bus bridge. He touches ACKNOWLEDGE on his tablet which uses the cellular data 
network to transmit his acknowledgement back to the ROC, where it is conveyed to Angela on her 
ATMS || workstation. Robert starts driving to the 7“ Street / Metro station. 


The buses supporting the bus bridge, transmit their location and passenger load information via the ATMS data radio 
system every 3 minutes the Metro fleet cellular data network to transmit the information every 30 
seconds. Antonio calls each bus supporting the bus bridge manually logs the time and passenger count for each bus 
bridge trip ATMS || automatically logs the bus bridge information including the bus bridge trip 
information and passenger loads. ATMS II displays this information and provides arrival predictions 
of the buses to the BOC and ROC controllers, Road Supervisors and field supervisors, Antonio manages 
the bus bridge and communicates with bus operators and rail supervisors using the ATMS voice radio system VoIP and the 
data messages via the ATMS data radio system Metro fleet cellular data network. 


Angela, the ROC Controller receives vehicle location information for the Red and Purple trains from her SCADA console. 
ATMS II receives information from the GPS receivers onboard the trains and beacons on the tracks to 
provide location information to Angela that is more accurate than from the SCADA for Red and 
Purple trains. ATMS Il also provide passenger counts and sends the data every 30 seconds via the 
cellular data network to the ROC. Angela, manages the rail related activities for the bus bridge and communicates 
with rail operators and field supervisors using rail voice radio system and the data messaging functions of ATMS ||. 


Dwight, the bus supervisor, uses his portable to communicate with Antonio, the BOC Controller, via the ATMS voice radio 
system VoIP, and uses his tablet to send messages as needed to Angela at the BOC and Robert, the rail 
field supervisor via the cellular data network. Dwight uses his tablet to view the locations of the 
buses supporting the bus bridge and the trains arriving at the 7th and Metro station. 


Robert, the rail field supervisor uses his portables to communicate with Angela, the ROC Controller, via the rail voice radio 
system and uses his tablet to send messages as needed to Antonio at the ROC and Dwight, the bus Road 
Supervisor via the cellular data network. Robert uses his table to view the locations of the trains on 
the Red and Purple Lines. 
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PASSENGER INFORMATION 


Barney enters a new run assignment on his headsign controller his train’s ATMS || MTD, which automatically 
updates his train’s headsigns with the new destination. Before the incident, his train was travelling from 
Hollywood toward downtown Los Angeles, with its headsign displaying the Red Line terminus of Union Station. Due to the 
Pershing Square blockage, his headsign now indicates 7** St / Metro Center as his train’s end destination. Passengers 
boarding Barney’s train see the headsign showing the train’s new final destination so they know they will not directly reach 
Union Station via this train. When Barney’s train reaches the 7*" St / Metro Center station, passengers who wish to continue 
to the Pershing Square, Civic Center / Grand Park, and Union Stations, will need to use the bus bridge. 


The Enhanced Multi-modal Real-time Alerts System, receives notification of the bus bridge from 
ATMS Il which in turn automatically sends rail service alert notifications to Metro’s website, API, 
Go511, smartphone applications, and social media such as Twitter and Facebook. The Alert System also 
sends the rail service alert information to transit passenger information system (TPIS) display signs. During the bus 
bridge, ATMS II provides the location of buses and trains, their predicted arrival information and 
passenger loads to Nextrip and website API, Go511, smartphone applications, and social media such 
as Twitter and Facebook. 


Grace, is riding the Red Line from Hollywood on her way to Union Station, when she hears an announcement on the PA 
system from Barney the rail operator that the Red Line is blocked at Pershing square and so the train will be terminating at 
the 7" Street / Metro station. Barney states in his voice announcement that a bus bridge has been set up to transport 
passengers who want to continue to Pershing Square, Grand Park/Civic Center or Union Station. Grace reads detailed 
information about the bus bridge that is display on the LCD monitor in her train car. The monitor 
shows the location of the Red Line blockage and a map with clear instructions about where to alight 
from her train and where to catch her bus bridge bus. Grace, though annoyed about the delay is 
relieved to see how well-prepared Metro is for this incident. Her train continues to 7“ Street / Metro Center 
station where Grace alights from the train. Grace receives guidance from Robert, the field supervisor who directs the 
movement of rail passengers out of their trains and up to the street to their bus bridge pickup location. Grace also sees 
information from ATMS || that is displayed on the rail stations signs. 


Grace, who has registered with Metro’s website to receive alerts about her commonly used routes, also receives a text 
message alert on her smartphone notifying her about the bus bridge and providing a url link. She selects the link 
from her text message and it opens in her smartphone’s internet browser, and uses her cellular 
carrier’s data connection in the underground station to access detailed information about the bus 
bridge and the locations of the buses supporting the bus bridge from Metro’s website. She notices 
another traveler has taken out his laptop and connected to his carrier’s Wi-Fi, which is available at the 
station to access the same information. There are also TPIS signs throughout the station that display information from 
ATMS II which directs Grace up from the underground station to the bus bridge pickup location. Grace is pleased to see that 
Marjorie’s bus is about to arrive to pick them up. 


Grace alights from her bus bridge trip at the Civic Center station. She receives rail departure info for her train to Union 
Station from the TPIS signs at station and via Metro’s website and app. 


CANCELLATION OF BUS BRIDGE 


Angela, the ROC Controller upon receipt of the alarms from the SCADA system that indicate electrical issues with the 
Pershing Square station, places telephone calls to the vendors who are responsible for the maintenance of the systems in 
an alarm state receives notification from the SCADA Message Gateway that the vendors have been 
automatically notified of the maintenance issue. Angela also relays information to Metro’s maintenance staff 
and if necessary security staff regarding the issues. Maintenance and security staff have direct access to the 


A-15 


September 2016 


BUS AND RAIL FLEET SYSTEMS STRATEGIC PLAN 
Prepared for Los Angeles Metropolitan Transportation Authority by EIGER TechSystems 


SCADA information related to the maintenance issue via the SCADA Maintenance HMI. Mark, who is the 
field supervisor who is responsible for the management of repair activities at the Pershing Square station, works with the 
maintenance staff to determine when the station can be reopened. 


After the repairs have been completed, Mark notifies Angela, the ROC controller via the rail voice radio system that the 
station is reopened and service can resume. Angela then uses her SCADA console to revise rail runs to resume normal 
service. SCADA updates rail run information via the TDB. This prompts Nextrip to update all predictions and 
transmit them to Metro’s website, API, Go511, smartphone applications, and social media such as 
Twitter and Facebook. 


Using the rail voice radio system, Angela calls all operators and supervisors on the Red and Purple Lines using the rail voice 
radio system announcing resumption of normal service. Angela uses her ATMS || console to send a message to 
all Red and Purple lines trains of the resumption of normal rail service via the Metro Fleet cellular 
data network. 


Angela uses her ATMS II workstation to cancel the bus bridge incident. She calls Antonio, the BOC 
controller, that the bus bridge is no longer needed. Antonio also sees the cancellation of the bus bridge on his 
ATMS || workstation. Angela uses an Everbridge workstation to remove the bus bridge from the Alert System, ATMS 
I| automatically removes the bus bridge alert from the Enhanced Multi-modal Real-time Alerts 
System causing the alert to be removed from website API, Go511, smartphone applications, and 
social media such as Twitter and Facebook, as well as from the transit passenger information system 
(TPIS) display signs. 


Barney, a rail operator reads the cancellation message on his MDT and sends an ACKNOWLEDGE. 
The acknowledgment message is sent over Metro’s fleet cellular data network to Angela at the ROC. 


Barney enters a new rail assignment on the MDT which automatically updates his train’s headsign 
with a new final destination. Barney uses his train’s PA to announce the resumption of regular service to the 


passengers on his train. The cancellation of the bus bridge in ATMS || automatically removes the alert 
messages regarding the bus bridge. 


Angela, the ROC Controller, uses her ATMS II workstation to send a bus bridge cancellation message 
via the Metro fleet cellular data network to the field supervisors assigned to the bus bridge. Robert 
a field supervisor assigned to the bus bridge, receives the cancellation message and acknowledges it 
on his tablet. The acknowledgement is sent back to Angela at the ROC via the cellular data network. 
Robert begins directing passengers to wait for trains. 


Antonio, the BOC Controller, uses his ATMS workstation to set up a group call via the ATMS voice radio system via VoIP to 
all of the road supervisors assigned to the bus bridge to announce the bus bridge is ending. He also uses his ATMS 
workstation to send a bus bridge cancellation message to the Road Supervisors via Metro’s fleet 
cellular data network. Dwight, a Road Supervisor, receives the message on his tablet or portable 
laptop and sends an ACKNOWLEDGE message via Metro’s fleet cellular data network back to Antonio 
and begins directing passengers who are waiting for a bus to return back down to the 7 and Metro station to board a 
train. When there are no more passengers waiting for a bus bridge bus, Antonio uses his portable radio and Antonio calls 
via the ATMS voice radio system via VoIP to let him know that there are no more passengers for the bus bridge. Antonio 
sends bus bridge cancellation messages to bus operators that are driving to the 7‘ and Metro station to pick up bus bridge 
passengers. The bus bridge operators receive the messages on their MDTs, send an ACKNOWLEDGE message to Antonio via 
the ATMS data radio system via Metro’s fleet cellular data network and return back to their divisions. 


When the bus bridge is cancelled, ATMS II automatically sends a message to the LCD monitors 
onboard the trains and on the TPIS monitors at the stations announcing the resumption of normal 
service on the Red and Purple lines. When the Enhanced Multi-modal Real-time Alerts System 
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receives the bus bridge cancellation notification from ATMS ll, it send an alert notification to 


passengers who have opted to receive alerts of the bus bridge cancellation. 
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The following table lists abbreviated names and descriptions for current/planned fleet system projects 
undertaken by LA Metro. This table is intended to be used in conjunctions with Figures 4 and 5 which 
provide an overview of existing and planned Metro projects and recommended projects. 


ID & NAME BRIEF DESCRIPTION 


CURRENT/PLANNED PROJECTS — IT Systems 


C/P.1 Golden Gate 


Metro is/has upgraded their databases that are crucial to many of the 
current and recommended fleet management systems to Oracle Golden 
Gate 12C. This version is particularly well suited to real-time data capture 
and distribution and data integration and replication, all of which is well 
suited to fleet system needs. 


C/P.2 Business Intelligence 


Metro has started a Business Intelligence development effort that 
combines data from a variety of source systems, including many fleet 
management systems. BI tools would like be expanded or enhanced as 
recommended fleet management systems come on-board. 


C/P.3 Integrated Corridor 
Management 


Metro is undertaking ICM studies and efforts that involve multiple modes 
in key travel corridors. When implemented ICM facilities would draw 
upon existing and recommended fleet systems for multi-modal 
functionality. 


C/P.4 Regional Assessment of 
Transportation Systems 
Operations 


Metro is undertaking regional assessments of transportation systems and 
these studies may have impacts or recommendations relevant to fleet 
systems implementations. 


C/P.5 DIMS 


Metro is in procurement for an integrated video request and distribution 
management system for bus vehicles, rail vehicles, and fixed facilities. 
This effort relates to several of the recommended projects that would 
build upon DIMS as discussed in the plan recommendations. 


C/P.6 HASTUS Upgrade 


HASTUS is the source of transit schedule and supporting information for 
existing fleet systems and is anticipated to remain in this role for the 
foreseeable future. Metro is planning on HASTUS versions upgrades that 
should be in place in time to support ATMS ll. 


C/P.7 Real-Time Trip Planner 


Metro is upgrading its trip planner to reflect and integrate available real- 
time information and alerts. Several of the traveler information projects 
recommended in this Plan could require additional future updates to the 
trips planner to make full use of Multi-Modal Alerts, Aggregated Real- 
Time Data, etc. 


C/P.8 M3 Architecture 


Metro has put out requests for information regarding options for 
replacing the M3 software platform used for maintenance management 
and monitoring. M3 has a number of interfaces with existing fleet 
management systems (including TBD, ATMS, and SCADA). The M3 
replacement system should consider the enhanced features, functions, 
and data available through the recommended projects in the Plan, 
including ATMS II, Yard Management systems, HMI SCADA projects, etc. 


C/P.9 E-Signage 


Metro is undertaking a project to promote integration of data from 
multiple transit providers (e.g. Metro and partner agencies) for electronic 
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bus signage at transit stops. This project would be a precursor to the 
recommended NTCIP compliant signage projects in the Plan. 


C/P.10 ESOC Study 


Metro recently completed updated studies for the ESOC facility that 
could support a combined BOC/ROC. 


C/P.11 Regional ITS Architecture 
Update 


Current and updated regional ITS architecture should review the role of 
fleet systems and the recommendations of this Plan to ensure on-going 
consistency. 


C/P.12 RIITS Modernization 


Metro is planning on updating RIITS which is a user of fleet systems data 
from ATMS and other sources. The recommended updates to fleet 
systems in this Plan should continue to provide data to RIITS, and RIITS 
may ultimately need to be updated over time to take full advantage of 
additional available data from the new fleet systems. 


C/P.13 ESOC Construction 


If ESOC moves forward, it may be beneficial to consider the transitions 
from ATMS to ATMS Il and potential coordination with ESOC construction 
(as well as ultimate plans for BOC and ROC locations). 


V.2 Centralized Cloud-Based VSS 


Metro is looking into options for cloud-based storage for some security 
and transit video. This effort could be integrated with DIMS. Additional 
cloud storage options are included as recommended projects in this Plan. 


CURRENT/PLANNED PROJECTS — Bus & Rail Systems 


C/P.22 Bus & Rail ITS Strategic 
Plan 


Metro undertaking a strategic review of bus and rail ITS elements. Any 
such effort should carefully consider the communications, CAD, on-board 
architecture and related recommendations in this Plan. 


S.1 Standardization of ARINC 
SCADA (except Green Line) 


Metro is updating the SCADA systems for its rail lines except for the 
Green Line. All of the SCADA systems will utilize the ARINC’s SCADA 
system. The standardization of the Green Line SCADA system will occur 
during the S.6 project. 


C/P.24 Next Generation BSP 


Metro is currently studying the next generation of Bus Signal Priority. 
Outcomes of this study will need to be incorporated into the fleet 
systems elements supporting BSP in both ATMS II and the on-board 
architectures. 


C/P.25 Platform Track Intrusion 
Detection System 


Metro is undertaking an enhanced intrusion detection system for 
platform/tracks and tunnels. This system is anticipated to provide alerts 
that could be integrated with fleet systems including SCADA and/or ATMS 
Il. 


AV.5 Dynamic Rideshare Pilot 
Project 


A Connected Vehicle effort by Metro that would represent an early CV 
project involving coordination of ridesharing and transit usage. 
Additional general discussion of this and related efforts are included in 
the Connected Vehicle section of the Plan. 


S.6 Standardization of ARINC 
SCADA (Green Line) 


Same as S.1, but for the Green Line. 


CURRENT/PLANNED PROJECTS — Communications 


B-3 


BUS AND RAIL FLEET SYSTEMS STRATEGIC PLAN 
Prepared for Los Angeles Metropolitan Transportation Authority by EIGER TechSystems 


September 2016 


ID & NAME BRIEF DESCRIPTION 


C/P.14 Cellular & LA-RICS Drive 
Testing 


Metro is currently running a single test vehicle to provide preliminary 
coverage and quality data comparisons between commercial cellular 
carriers and LA-RICS data networks. Recommendations are to expand 
this testing effort as part of the recommended communications projects 
and Connected Fleet Vehicles & Facilities project. 


AV.1 LA County DSRC Pilot 


C/P.16 


Metro is participating in the LA County Dedicated Short Range 
Communications (DSRC) Pilot project which is a backbone for Connected 
Vehicle efforts using DSRC in the dedicated 5.9GHz range. 


Upgrades to Metro yard WiFi systems for upload/download of video and 
rail systems data to/from rail vehicles. See also C/P.20 and Y.1 & Y.2 as 
they are all interrelated depending on funding and implementation 
timeframes. 


CURRENT/PLANNED PROJECTS — On-Board Systems 


C/P.17 Farebox WPA2 
Encryption 


Metro reviewing potential efforts to enhance farebox/smart card 
encryption. This could have implications for on-board communications 
routing through the MGR as recommended in the Plan. This should also 
be reviewed in conjunction with the Metro Connected Fleet Vehicles & 
Facilities project. 


C/P.18 All Door Boarding Pilot 


Pilot effort to review front/rear door simultaneous boardings, particularly 
in conjunction with TAP use. 


C/P.19 ATMS BSP Upgrade 


Metro is undertaking efforts to integrate the current Bus Signal Priority 
(BSP) functionality into the current ATMS system. This would support 
communications between the IVU and the signalized intersection using 
802.11b. This effort should be complete prior to the start of ATMS II. 


C/P.20 Connected Fleet Vehicles 
& Facilities 


A core and key element of the recommended on-board architectures in 
the Plan for bus and rail, the Connected Fleet Vehicles & Facilities project 
is currently being planned/budgeted by Metro. This would deploy MGRs 
and cellular data on the entire vehicle fleet (bus and rail). If this project is 
not accomplished prior to ATMS II, then the final roll-out of these 
functions would have to be part of ATMS Il. 


C/P.21 Farebox Near-Real Time 
Communications 


Metro’s farebox/TAP groups are reviewing options to support enhanced 
communications that would reduce the delay between customers 
initiating or recharging a TAP card and having this change recognized on 
buses. The transitioning on-board architecture recommends that options 
for running this communications through the MGR be strongly 
considered and reviewed, but ultimately the decision will have to be 
based on more detailed review as part of a specific project effort. 


0.6 Planned APC 
Replacement/Upgrade 


Metro has indicated that APCs (automated passenger counters) on some 
or all buses may be replaced as part of a bus fleet may occur prior to 
ATMS II roll-out. This would be part of a separate Metro project, but 
should consider the on-board architecture recommendations as well as 
ATMS Il implementation plans. 
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T.1 Multi-modal Alerts Pilot Metro has been undertaking a six month pilot of a real-time alerts system 
that bridges the gap between the incidents entered and tracked in ATMS 
and the customer information dissemination systems. It is focused on 
allowing rapid entry, review, and release of relevant customer service, 
construction impact, and related alerts to existing and planned Metro 
information systems. This pilot relates to recommendations for some 
traveler information projects in this plan, as well as potential functionality 
for ATMS Il. 
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The following table provides definitions for key terms and acronyms used throughout this Plan. 


TERM/ACRONYM DEFINITION 


TERMS 

Long Term 8 to 15 years from the time the Strategic Plan was drafted. 
Near Term 5 to 7 years from the time the Strategic Plan was drafted. 
ACRONYMS 

ADA Americans with Disabilities Act 

AIM® ARINC Advanced Information Management 
APC Automated Passenger Counter 

API Application Program Interface 

APTA American Public Transportation Association 
ASA Automated Stop Announcements 

ATMS Advanced Transportation Management System 
ATP Advanced Train Protection 

AVA Automated Voice Annunciation 

AVL Automatic Vehicle Location 

BART Bay Area Rapid Transit 

BOC Bus Operations Center 

BOS Boston (airport ID) 

BSP Bus Signal Priority 

CAD Computer Aided Dispatch 

CCTV Closed Circuit Television 

CENTRO Syracuse NY transit agency 

CTA Chicago Transit Authority 

CTS Cable Transmission System 

DIMS Digital Information Management System 

DSRC Dedicated Short Range Communications 

DVR Digital Video Recording 

ESOC Emergency Services Operations Center 

FTE Full Time Equivalent 

GPS Global Positioning System 
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GTFS General Transit Feed Standard 

HMI Human Machine Interface 

ICU On-board video surveillance systems 

ITS Intelligent Transportation Systems 

IVU Intelligent Vehicle Unit 

KVM Keyboard Video Mouse 

LA-RICS Los Angeles Regional Interoperable Communications System 
LADOT Los Angeles Department of Transportation 

LAX Los Angeles airport code 

LCD Liquid Crystal Diode 

LMR Land Mobile Radio 

LTE Long-Term Evolution 

MBTA Massachusetts Bay Transportation Authority 

MDT Mobile Data Terminal 

MGR Mobile Gateway Router 

MTC Metropolitan Transportation Commission (Bay Area, CA) 
NFTA Niagara Frontier Transportation Authority 

NICE Nassau Inter-County Express (Long Island, NY) 

NTCIP National Transportation Communications for ITS Protocol 
OEM Original Equipment Manufacturer 

PLC Programmable Logic Computers (SCADA) 

PRTT Priority Request to Talk 

QoS Quality of Service 

RFID Radio Frequency Identification 

RFP Request for Proposals 

ROC Rail Operations Center 

ROM Rough Order of Magnitude 

RSS Received Signal Strength 

RTD Regional Transportation District (Denver, CO) 

RTPI Real-Time Passenger Information 
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RTT Request to Talk 

SCADA Supervisory Control and Data Acquisition system 
SEA Seattle airport code 

SFMTA San Francisco Metropolitan Transportation Authority 
SFO San Francisco airport code 

SIL Safety Integrity Level 

SMART Suburban Mobility Authority for Regional Transportation 
SMS Short Message Service 

SORTA Southern Ohio Regional Transportation Authority 
SWOT Strengths, Weaknesses, Opportunities, Threats 

TAP Transit Access Pass 

TDB To Be Determined 

TIS Traveler Information System 

TPIS Transit Passenger Information System 

TSP Transit Signal Priority 

TWC Track Wayside Circuits 

VHM Vehicle Health Monitoring 

VLU Vehicle Logic Unit 

VoIP Voice over Internet Protocol 

VSS Video Surveillance System 

VTA Valley Transportation Authority 

WLAN Wireless Local Area Network 

WMATA Washington Metropolitan Area Transportation Authority 
WRTA Worcester Regional Transit Authority 

WSCA Western States Contracting Alliance 
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